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]> 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/ProxyMethodServerCallHandlerEn > dToEndTests.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/ms >> gid/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/CAOMCPe%2BX6ujxBANJ-YQYNm6tUA9BKBZxCZfg%2BHsvcV%3DOP3frTQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
