Good catch here - definitely for host we want to set rather than append, but I'm surprised we allow host override - we generally disallow setting the special : h2 headers in most operations.

If we decide we want to allow this for host I think we need to at the very least special case :authority :scheme :path etc, and probably do what we discussed on the retry PR and change the API to allow for "append or replace" semantics.

cc @markdroth

I would advise not allowing HTTP/2 special headers to be set for gRPC. I don't know about the EnvoyGprc implementation (which I assume is what this file is for), but in Google gRPC, we don't expect these to be set by the application (at least not directly -- there are some options that can be used to affect how we set them, but they're not generally necessary).

The host is required mainly because the async client is very limited. This grpc client is used by a filter which may need a grpc client(e.g. external authz), or xds client.
The header manipulation is not supposed to be simple: no evaluation, no untrusted value.
The grpc headers are actually as simple as a header set
see

Personally I don't want to promote the grpc header factory as complicated as the one in route entry, which represents the scenario which requires
a base header map plus a header add/delete engine, unless this if branch is proved to be hard to handle.

I agree that this should not be complicated. And I think that representation of headers is just fine. But I don't understand why users would need to put the host header in initial_metadata.

Google gRPC will populate the ":authority" header internally; it does not need to be passed in by the user in initial_metadata. I think EnvoyGrpc should do the same thing.

To say this another way, I think that users should be able to switch back and forth between EnvoyGrpc and GoogleGrpc without changing their initial_metadata field. Since GoogleGrpc can't handle the host header being set in initial_metadata, EnvoyGrpc shouldn't do it either.

@markdroth I highly agree with you that we should make envoygrpc and googlegrpc interchangeable as far as possible.

This cluster_name provide both :authority(as string) and L4 addresses(as the reference to an envoy cluster).

How is :authority filled in googlegrpc?

In Google gRPC, the ":authority" header is set based on name used to create the gRPC channel. That's essentially the name specified here:

@markdroth Google Grpc seems support override authority by ClientContext::set_authority().

Does it mean we can add the authority field for both google grpc and envoy grpc now?

You can set it that way, but it's almost never necessary. That mechanism was added for some fairly rare virtual hosting scenarios.

My suggestion would be that instead of adding an authority field to the top-level GrpcService message, you instead add this in the EnvoyGrpc message. Having one field that works for both EnvoyGrpc and GoogleGrpc seems confusing, since the semantics are different -- this is probably going to be necessary a lot more for EnvoyGrpc than for GoogleGrpc, since the latter already gets this from the target_uri field. If we ever run into the rare case where this needs to be overridden for GoogleGrpc, we can add a separate field in that message.

Thanks @markdroth!
The :authority has the exact semantic on both google grpc and envoy grpc.
I admit my pain point now is to override host at envoy grpc b/c as you mentioned I could fill the targeturi with my desired :authority.
It's likely we will want L4 address be independent virtual host in the future at istio, but we are not there yet.

I am following your comment to make it EnvoyGrpc only