Allow complete override of User-Agent Header on a per-RPC level from grpc client libraries

[Asad Ali]

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. 

 

[Asad Ali]

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

[Carl Mastrangelo]

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

[Asad Ali]

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