client: Add CallOption for setting authority; allow even without WithInsecure

[carnott-snap]

Use case(s) - what problem will this feature solve?

I would like to write a grpc.XxxClientInterceptor that is able to safely extract and interact with the authority header.

Proposed Solution

Since this information is currently hidden inside grpc.ClientConn, and that struct is an input to the grpc.XxxYyyInterceptor types, it seems reasonable to add a method to extract it.

func (cc *ClientConn) Authority() string {
        return cc.authority
}

Alternatives Considered

Func

Instead of a method, this could be implemented as a function, but does not read as well.

func Authority(cc *ClientConn) string {
  return cc.authority
}

Field

Currently authority is immutable, thus thread safe. Exposing a field would be easier than a method, but would break both guarantees.

type ClientConn struct {
    Authority string

    // ... other fields elided ...
}

Parameter

Since both grpc.XxxClientInterceptor types are EXPERIMENTAL APIs, you could just expose the value directly as a parameter. This seems pretty heavy for something that is not always required, and it double embeds the value (authority and cc.authority), so more edge cases and failure modes need be tested.

type UnaryClientInterceptor func(ctx context.Context, method, authority string, req, reply interface{}, cc *ClientConn, invoker UnaryInvoker, opts ...CallOption) error

type StreamClientInterceptor func(ctx context.Context, desc *StreamDesc, cc *ClientConn, method, authority string, streamer Streamer, opts ...CallOption) (ClientStream, error)

Additional Context

Authority is an h2 pseudo header set by grpc.WithAuthority. This grpc.DialOption binds the given string to grpc.dialOptions.authority, then grpc.Dial and grpc.DialContext bind against grpc.ClientConn.authority when called.

[dfawley]

Note that it's actually possible for the name resolver to override the authority by setting the ServerName field in resolver.Address:

https://github.com/grpc/grpc-go/blob/master/clientconn.go#L1219

This means exposing ClientConn.authority directly could result in an inconsistency.

The real authority is only passed outside gRPC in the credentials.ClientHandshake for now. That could then be retrieved by accessing the Peer if the credentials included it in the AuthInfo (our TLS credentials currently do not; this could potentially be added, or you could implement your own credentials wrapping ours and storing the authority in AuthInfo to be retrieved later).

The Peer is currently visible in a few ways:

1. in unary RPCs via the Peer CallOption, only after the RPC completes. This means a unary interceptor also can't access it until after the RPC completes.

2. in streaming RPCs while the RPC is in flight. This means a streaming interceptor can access it early in the RPC's lifecycle.

3. to stats handlers when OutHeader is called at the start of the RPC.

What are you ultimately trying to accomplish by accessing the authority?

[carnott-snap]

We have use cases where grpc.Dial's target must differ from the authority header. This requirement exists because our reverse proxy uses authority for routing (similar to how the host header can be used), and target for DNS and TLS SNI. This works as expected using grpc.Dial("proxy.net", grpc.WithAuthority("service.net")), but is obscured from interceptors.

[menghanl]

What are you trying to do with authority in the interceptors? Is it just for logging or other purposes?

[carnott-snap]

What are you trying to do with authority in the interceptors? Is it just for logging or other purposes?

Logging is certainly an important feature, but more generally we desire to customise the outgoing request based on the authority header, as it is used in authentication on the receiving end.

After some discussions with colleagues, it became clear that grpc.XxxClientInterceptor may not be the right abstraction level for what we are targeting. Our changes need to happen at the http layer, including but not limited to header manipulation, and it seems like grpc.XxxClientInterceptors are more about modifications at the grpc layer; modifying methods, req/resp validation, etc. Furthermore, the manipulations we want are agnostic to unary/stream. So, it seemed to us that implementing a new grpc.HTTPInterceptor may actually suit our needs better, thoughts?

[dfawley]

Implementing an HTTP-level interceptor is not something we have plans or resources for at this time. It sounds like you may need a L7 proxy to do what you need, or possibly to reassess your design since this doesn't sound like anything we've heard requested before.

[stale]

This issue is labeled as requiring an update from the reporter, and no update has been received after 7 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[carnott-snap]

I should be a little more concrete, since I think my abstract discussion was both a hard piviot and may have scared you off. We are not looking to implement custom HTTP primitives, just interact with H2 headers via metadata.MD. It would be nice to have defined the exact scope for the grpc.XxxClientInterceptors, but it is experimental, so that is reasonable.

For our use case we need:

• access to the client/request metadata, chiefly for extracting the host/authority header information
  • this information is verified by a proxy, thus the discussion about H2
• the ability to set custom headers
  • the header will bind in information about where there request is going, and will also be consumed by the proxy

This reverse proxy listens on proxy.net and uses the host/authority header to route to upstream resources, like service.net. It also checks metadata/header information for service.net. Is there a more canonical way to do this?

[stale]

This issue is labeled as requiring an update from the reporter, and no update has been received after 7 days. If no update is provided in the next 7 days, this issue will be automatically closed.

[carnott-snap]

I believe I have provided satisfactory clarification, but if not please let me know what more would be helpful.