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 On Fri, Feb 3, 2017 at 7:28 PM, 'Carl Mastrangelo' via grpc.io < [email protected]> wrote: > 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. > > On Friday, February 3, 2017 at 2:24:17 PM UTC-8, Joey Bratton wrote: >> >> 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 >> > -- > 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 post to this group, send email to [email protected]. > 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 > <https://groups.google.com/d/msgid/grpc-io/582fc46a-4f5c-47de-9636-b3e14f01e921%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. 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/CAOMCPeJJZqcwMtFzjcFe5vFnqXvdLWR94%2BiAu98LGg3C_kaHXQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
