On Thu, Apr 14, 2022 at 4:13 PM Peter Wiese <[email protected]> wrote:
> Per the gRPC over HTTP/2 spec > https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md#requests > > I read that as either form is acceptable. If that is true my other > question is if a gRPC server receives headers in either form are they > semantically the same? > I'm a bit confused what wasn't explained by this about Custom-Metadata; it seems you saw it: > Duplicate header names may have their values joined with "," as the > delimiter and be considered semantically equivalent. So yes, they are semantically the same. This is actually an HTTP-ism exposed in gRPC, so the HTTP spec talks about this <https://www.rfc-editor.org/rfc/rfc7230#section-3.2.2> if you care. A grpc-dotnet client (which replaces the wrapper over Grpc.Core) turns > multiple metadata items into a single HTTP/2 header and a grpc-dotnet > server reads it back as a single header with a comma-separated value (as a > string). > That's okay. Note that it would *not* be okay to split on ',' within the API; that can only be done with knowledge about that specific header's format. (E.g., maybe it supports commas in double quotes like CSV, or allows backslashes before commas to escape, or maybe it isn't multi-valued at all) Note that proxies can also perform this transformation, so every language may see the combined form. I think it would be quite fair to only support single-valued headers within a gRPC API for non-binary headers. It is much easier to use and less prone to buggy usage. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oN0_Aa8syjXM9f99P_Niy8YTE1CPSTqjOLL8C%2BV-D9fOg%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
