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
On Monday, February 6, 2017 at 10:28:39 AM UTC-8, Joey Bratton wrote: > > 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 > > On Sat, Feb 4, 2017 at 1:38 AM, Joey Bratton <[email protected] > <javascript:>> wrote: > >> 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] <javascript:>> 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] <javascript:>. >>> To post to this group, send email to [email protected] >>> <javascript:>. >>> 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/dc2f60a3-ce34-4dd4-b007-e9be1cd80ef4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
