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/942b7518-4f1e-4da6-98a1-04b1bdcb5e4e%40googlegroups.com.
