Add guidance on HTTP header -> gRPC mapping

[toumorokoshi]

This issue discusses a generic approach to map HTTP headers to gRPC.

Given a significant number of IETF RFCs around HTTP revolve around the usage of headers, applying a standard practice on how these mappings would work would allow us to quickly make decisions about how to adopt these RFCs.

Examples include:

• Add guidance on support for Prefer header [RFC 7240] #285
• replacing usage of update etag with AIP-154 ifMatch? #241

Feel free to add information that could contribute to the decision!

[toumorokoshi]

One of the major challenges is to find a canonical way to map headers that feels natural in gRPC.

grpc metadata looks to be introduced for this purpose, so if there was a standard way to do this type of routing in the popular grpc-http+json mappings, then mapping to metadata might be an acceptable recommendation: it requires extracting fields from metadata which doesn't always feel natural in the protobuf clients, but does serve the purpose.

grpc-gateway provides a standard way to apply these mappings, that we could add helpers or.

envoy supports some header mappings in their grpc mapping.

[rambleraptor]

At first glance, grpc-gateway handles metadata through the use of interceptors (middleware). A middleware approach works great for some concepts like auth.

For something like etag/Prefer, you want the header value traversing down to the RPC itself. I'm not sure that a middleware approach would allow for that.

One approach would be to add fields to the RPC request message and tag them with their headers. An interceptor would be responsible for translating these headers to the request message.