[grpc-java] Accessing pseudo headers in server interceptors

[Joey Bratton]

It looks like https://github.com/grpc/grpc-java/pull/2235 refactored how the header Metadata gets populated and the "pseudo" headers (e.g. `:authority`, `:path`, etc.) are no longer included in the `headers` object that is passed to the server interceptor. Is there some other mechanism for getting access to those headers? In particular, we're interested in the `:authority`. We're looking at co-process/proxy solutions and if we were going to build a custom solution directly on gRPC then it would be useful to get access to the authority to potentially use it for request routing.

Hypothetical authority-based routing scenario:

- DNS for *.services.local is routed to localhost

- Client makes outbound call to target.services.local

- Proxy co-process receives the request and parses `target` out of the authority, then creates a new channel with a name resolver that knows how to discover the real address(es) for the target service and forwards the request.

Thanks!

Joey Bratton

[Carl Mastrangelo]

I believe what you are looking for is the yet-to-be-implemented HandlerRegistry.lookupMethod  override with the authority.  We avoid putting the pseudo headers in the Metadata (and strip them out if you give them to us) because they cost latency and almost no one needs them.  

[Joey Bratton]

I don't think the HandlerRegistry approach would work in this scenario because the proxy wouldn't actually have any of those handlers registered. I've got a repo with some proof of concept code for this hypothetical gRPC-based proxy/co-process:

https://github.com/joeyb/grpc-java-proxy

There are some end-to-end tests that should give a good overview of how it works:

https://github.com/joeyb/grpc-java-proxy/blob/master/src/test/java/org/joeyb/grpc/proxy/ProxyMethodServerCallHandlerEndToEndTests.java

It takes advantage of the ServerBuilder#fallbackHandlerRegistry to catch all incoming requests and forward them along to their real destination. Right now I've got it set up to do that request routing via a custom `Host` header. That approach works, but it's a little less elegant because the client has to manually add the header. The authority-based approach would save a step for the client and allow the proxy to figure out the destination via convention in the authority used on the call to the proxy.

So with that in mind, I have a couple follow-up questions:

1. Are there any glaring issues with the overall gRPC-based co-process approach? We're evaluating other options (e.g. Envoy and Linkerd), but there are some compelling arguments for building directly on gRPC. Foremost that it allows us to build all of the co-process functionality using the existing interceptor, name resolver, and load balancer infrastructure. That would make it all usable directly in fat clients/servers in scenarios where deploying a co-process is difficult.

2. Does that seem like reasonable justification for passing the authority header down to interceptors/handlers? Or maybe provide an extension point in the header decoder so that an app could include any of those pseudo headers in the header metadata, if needed? The latter seems like a good way to still allow access and avoid the slippery slope of deciding which pseudo headers are important enough to be passed along. If that approach makes sense, I could put together a PR.

Thanks!

Joey

--
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 grpc-io+unsubscribe@googlegroups.com.
To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/582fc46a-4f5c-47de-9636-b3e14f01e921%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Joey Bratton]

After digging in to the HandlerRegistry approach further, it looks like we actually could make that work if it were fleshed out. Sorry about that, I misunderstood how that method was intended to be used. Since that API is already partially fleshed out, I'll just continue down that path and put together a PR that finishes fleshing it out.

Thanks!

Joey

[delt...@gmail.com]

Per the recommendation above, I've implemented the authority API for HandlerRegistry. Please let me know what needs improving. https://github.com/grpc/grpc-java/pull/2704

To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.

To post to this group, send email to grp...@googlegroups.com.
Visit this group at https://groups.google.com/group/grpc-io.