To support client-side demultiplexing needed by much of the upcoming routing technologies, the client needs to be able to extract the exact piece of information that is relevant.
The current proposal is the minimal amount of extraction support needed for the the use cases we are targeting. Any future expansion should be relegated to standard extraction/transform methods, for example RE2 or CEL. (I personally would be fine with using RE2 now, though that adds a dependency on the RE2 lib, where this simple form likely doesn't add any deps). Note that the interpretation of the extracted contents are still opaque to GRPC. GRPC just needs to be able to test for equality. On Thu, Feb 2, 2017 at 1:43 PM Louis Ryan <lr...@google.com> wrote: > On Thu, Feb 2, 2017 at 1:19 PM, Alfred Fuller <arful...@google.com> wrote: > > I think this type of config is very service centric, not interface > centric. For example, look at the LRO API. Different services use the same > protobuf, but have different resource name formats. If the requirement was > copy a field verbatim it 'might' work to define the same extraction for all > services that implement LRO, but the requirement here is that the client is > able to uniquely identify an 'affinity key', so the protocol must be able > to extract the exact substring needed. > > > I'm not necessarily saying it has to be codegen though that might be a > reasonable option for a wide variety of folks where interface and service > are not decoupled. > > My primary concern is how much GRPC has to know about whats happening. > GRPC shouldn't have to know anything more than > > 'higher layer please provide me a header value for this opaque rule that I > don't understand' > > perhaps with an indication of whether the provided value is binary or not. > > > > I can also see some services implementing a routing layer that is happy to > inspect everything, and in those cases, no extraction is needed even though > the same interface is exposed. > > Also, this eliminates the problems of clients using old configuration with > new infrastructure. > > So I would say this is not interface configuration, so it should not be in > the interface definition (i.e. the proto files). > > On Thu, Feb 2, 2017 at 1:00 PM Louis Ryan <lr...@google.com> wrote: > > I'm a little confused by this spec. Given that protobuf is backed by a > significant amount of code-generation and expression handling machinery why > is the spec putting responsibility for the extraction and formatting of > these headers on the GRPC runtime? > > Is there some requirement to be able to configure the field extraction > behavior dynamically for APIs that did not anticipate the need for it when > they were launched? If so it seems like that responsibility should rest > entirely on the protobuf runtime and the spec for GRPC should just talk > about how to talk to it to get something extracted. The same would be true > for other encoding runtimes. > > Given that protobuf has (or will have) a standard expression language it > seems like that is what should be passed up to the protobuf runtime > > On Wed, Feb 1, 2017 at 4:28 PM, Alfred Fuller <arful...@google.com> wrote: > > +Trevor Schroeder <trev...@google.com> what is easiest for the GFE and > friends? Base64 decoding a header, url unescaping a header or something > else? > > (I like the idea of %encoding for strings and base64 encoding bytes, > though if I had to pick only one it would probably be base64, as the blowup > from that is fixed and known) > > On Wed, Feb 1, 2017 at 10:02 AM Mark D. Roth <r...@google.com> wrote: > > On Wed, Feb 1, 2017 at 9:57 AM, Eric Anderson <ej...@google.com> wrote: > > On Wed, Feb 1, 2017 at 9:38 AM, Mark D. Roth <r...@google.com> wrote: > > Right off the cuff, I can think of a few possible options here: > > 1. Always base64-encode the extracted values. > 2. Do base64 encoding only when non-ASCII characters are actually present. > 3. Simply strip out non-ASCII characters. > > > There's also the option of encoding the special characters. Say, with > %-encoding. We're doing this for status messages. I think we are sad each > time we have to do this, but it frequently seems to be the least-bad > solution. > > Note this would get pretty strange (from a parsing perspective) when > values are binary, not text. So we may want a different solution for binary. > > > You're right, that is another viable option. And I do like the fact that > it makes things easier to debug in the common case, where the string is > mostly ASCII but may have a small number of non-ASCII characters. > > The down-side of this approach is that, as you pointed out, we would > probably want a separate solution for binary data. That would mean two > different code-paths and probably some way to indicate which one we want to > use for each header extraction spec. > > Alfred, what are you thoughts on all of this? > > > -- > Mark D. Roth <r...@google.com> > Software Engineer > Google, Inc. > > > -- 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+unsubscr...@googlegroups.com. To post to this group, send email to grpc-io@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/CAHZencYTYz4JtXkoMXWK%2BM%2BPB%2BrX3%3DZgVcjGEDhb9-b5YASkvA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
