On Wed, Feb 1, 2017 at 9:14 AM, 'Eric Anderson' via grpc.io < [email protected]> wrote:
> On Wednesday, February 1, 2017 at 8:52:57 AM UTC-8, Mark D. Roth wrote: >> >> What character encoding do they use for that field, UTF-8? How can we >>>> tell what character encoding is in use? I think we'd need some way to >>>> figure this out in order to support it. >>>> >>> >>> it is raw bytes, so no encoding (it is a serialized internal protobuf) >>> It does not require splitting (in fact any modification would be harmful) >>> Maybe make the delimiter optional? (and when it is set, the field must >>> be a string). >>> >> >> Actually, I think there's a more fundamental problem here. HTTP2 headers >> are limited to ASCII characters (see https://tools.ietf.org/ht >> ml/rfc7540#section-10.3). Given that, the only way we could support >> this would be to encode it somehow in the header value. >> > > Isn't this a problem for strings as well, as currently defined in the > gRFC? How are strings containing non-ASCII or illegal characters handled? > That's a really good point. I guess the only real difference between string fields and bytes fields is that the former may be less likely to have non-ASCII characters, but we still have to handle other characters somehow when they do occur. 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. Option 1 seems like it would be easiest to implement, although it might make things a bit harder to debug. Also, we would probably need to automatically append a "-bin" suffix to header field names. Option 2 is slightly more complex, because we would have two different encodings, depending on what we find in the request, and the server would need to know to check for both of them (i.e., check for both "${header}" and "${header}-bin", the latter with base64 encoding). This might make debugging a bit easier in the common case (no non-ASCII characters), but it would leave a potentially rare edge case that might be harder for people to remember to think about. I suspect that option 3 won't work, because anyone using those characters in the relevant fields presumably needs them as part of their key. Of course, both options 1 and 2 rest on the assumption that the server can handle the base64 decoding. Alfred, I'd like your feedback on that. > -- > 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/1403c8d6-4535-46ee-9174-c0c0ed4addc7%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/1403c8d6-4535-46ee-9174-c0c0ed4addc7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- Mark D. Roth <[email protected]> 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 [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/CAJgPXp4z4os9ph6R9NpgF6Qps4VJw8wFCtCSwL%3DdRuUdEhWQ0w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
