On Wednesday, June 12, 2019 at 9:38:27 AM UTC-7, Carl Mastrangelo wrote: > > Probably a better place to bring this up is as an issue on the GitHub > tracker, as a feature request: https://github.com/grpc/grpc-java/issues > > opened: https://github.com/grpc/grpc-java/issues/5874
On Tuesday, June 11, 2019 at 12:40:18 PM UTC-7, Asad Ali wrote: >> >> bump. >> >> i am not sure if this was the right forum to bring this up. >> any advice on who/where to continue this conversation with is much >> appreciated.. >> >> -A >> >> On Friday, June 7, 2019 at 4:21:58 PM UTC-7, Asad Ali wrote: >>> >>> tl;dr >>> >>> This is a followup from a discussion that was initiated on gitter >>> grpc/grpc channel. >>> Currently the grpc/java library reuses the User-Agent from the channel >>> for each RPC >>> and discards User-Agent by treating it as a reserved header. >>> >>> However, User-Agent is not a reserved header and this creates >>> complications >>> when trying to write a proxy-like gRPC service for HTTP endpoints that >>> care >>> about User-Agent for response customization. >>> >>> Posting it here to get more ideas about how to resolve this. >>> >>> quoting the conversation below: >>> >>> Asad @asadali Jun 04 13:10 >>> What was the underlying reason for the restriction on not allowing >>> User-Agent >>> to be overridden on a per-call basis? can't seem to find a spec which >>> reserves >>> the User-Agent string for gRPC/HTTP2 and yet there is code in place in >>> the >>> libraries (grpc-java/ grpc-go ..) to discard any user-supplied metadata >>> regarding User-Agent and always use the channel's value eg: >>> Utils.convertServerHeaders >>> >>> Asad @asadali Jun 04 13:16 >>> use-case: >>> client ---> httpSVC-A ---> grpcSVC-B ---> httpSVC-C >>> how can the client's user-agent be conveyed to httpSVC-C? if A-B have >>> ONLY one >>> channel open between them with a channel-level User-Agent that can't be >>> overridden >>> @ejona86 ^ question regarding user-agent behavior >>> >>> Eric Anderson @ejona86 Jun 04 14:34 >>> @asadali, user-agent is a built-in feature as gRPC itself sends it. >>> There is >>> an API to change what gRPC sends, but there didn't seem to be any need >>> to allow >>> it to be changed per-RPC. >>> >>> Asad @asadali Jun 04 14:43 >>> @ejona86 we seem to have a use-case in which a per-RPC user-agent will >>> make >>> things easier for us. The alternate is to use custom metadata fields to >>> preserve this information. that approach seems non-standard and we were >>> hoping >>> to avoid it. Will it be possible to include a per-RPC user-agent in >>> gRPC? i >>> will be happy to code it up. but based on what i read in past issues, >>> this >>> request was repeatedly turned down. >>> >>> Eric Anderson @ejona86 Jun 04 14:44 >>> That is a cross-language decision. You would need to make clear what the >>> use-case for it is. Right now, it isn't clear what the use-case is. >>> Oh. I see now. >>> You want to communicate the origin client's user-agent to SVC-C >>> Yeah. That's not appropriate for user-agent. >>> >>> Asad @asadali Jun 04 14:45 >>> ack >>> >>> Eric Anderson @ejona86 Jun 04 14:46 >>> .... unless you are making something closer to a proxy. Maybe. It sort >>> of >>> seems like a can of worms. It just makes a mess of things. >>> But I think I understand now. >>> >>> Asad @asadali Jun 04 14:48 >>> so the intermediate gateways aren't pure proxies but maybe more like >>> aggregators. in the non-GRPC world, the implementation made an >>> assumption that >>> User-Agent is the originating client's user-agent. and all intermediate >>> hops >>> honored that. I agree, that this is a very loose reading of the spec. I >>> feel >>> the more logical method is to update the user-agent on each hop >>> however, systems built around that assumption aren't happy when they >>> lose this >>> info :( IMO, gRPC clients can default to per-channel behavior but the >>> choice >>> should ultimately be left to the user if they want to override it >>> >>> Eric Anderson @ejona86 Jun 04 14:51 >>> Well, today the application can't set the entire user-agent. gRPC will >>> always >>> include itself in the user-agent. I'm trying to check what HTTP says to >>> do for >>> user-agent and proxies. >>> >>> Asad @asadali Jun 04 14:52 >>> yeah i can use another opinion on this. and current gRPC behavior is >>> what I am >>> trying to rationalize. does it need to always include its user-agent? >>> >>> Eric Anderson @ejona86 Jun 04 17:31 >>> @asadali, proxies do forward the user-agent. We do want to enable grpc >>> proxies, >>> so that does mean we should forward the user-agent. Although on the >>> server, any >>> compatibility quirks would generally be with the proxy, not the >>> end-client. So >>> it still seems muddled, but it does seem we should consider it. >>> >>> >>> >>>> -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/4bcafa6a-c962-435f-a309-f8ecee7a5ff1%40googlegroups.com.
