On Tue, Jan 31, 2017 at 9:44 AM, Alfred Fuller <[email protected]> wrote:
> > > On Tue, Jan 31, 2017 at 8:32 AM Mark D. Roth <[email protected]> wrote: > >> On Mon, Jan 30, 2017 at 9:05 PM, Alfred Fuller <[email protected]> >> wrote: >> >> "When protocol buffers are used for the payload, this must refer to a >> non-repeated string field." >> Datastore needs support for a 'bytes' field for the transaction >> identifier. >> >> >> 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/html/rfc7540#section-10.3). Given that, the only way we could support this would be to encode it somehow in the header value. gRPC does have a pre-existing convention that when a header name ends in "-bin", then the value is automatically base64-encoded and huffman-compressed. We could presumably use this mechanism in this case (with the restriction that the header name must end in "-bin"), but would we be able to do the required request routing based on the encoded value? > > >> >> >> for the user example, you would almost want to split on the @ and keep >> the second segment (the domain name). >> >> >> That would require adding yet another field to the header extraction spec >> for the number of leading fields to skip. Do we actually have a use-case >> for that? If not, I don't want to add unnecessary complexity. >> >> The example in the doc was just meant to illustrate that the delimiter >> character can be anything; it wasn't meant to be a realistic example. >> > > If it is not a real example no point in complicating the API at this > moment (I could see it being a real use case to someone), though maybe the > field names should use slicing nomenclature incase this ever changes. > If and when we actually run into this case, we can add new parameters for slice notation. > > >> >> >> On Mon, Jan 30, 2017 at 3:28 PM Alfred Fuller <[email protected]> >> wrote: >> >> Thanks! >> >> +Ed Davisson <[email protected]> +Louis Ryan <[email protected]> >> >> On Mon, Jan 30, 2017 at 2:14 PM Mark D. Roth <[email protected]> wrote: >> >> I've created a gRFC for the header extraction mechanism we're working on: >> >> https://github.com/grpc/proposal/pull/9 >> >> As per the gRFC process, please keep all design discussion on this >> thread. All comments welcome. >> >> Carl, can you please provide content for the Java implementation? Thanks! >> >> Please let me know if you have any questions or comments. >> >> -- >> Mark D. Roth <[email protected]> >> Software Engineer >> Google, Inc. >> >> >> >> >> -- >> Mark D. Roth <[email protected]> >> Software Engineer >> Google, Inc. >> > -- 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/CAJgPXp50XQTZzkckm%2BMVHGqmh%2BoMP9yGf6O75ZRU7T%2BH2M7ZPg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
