One use case Turbine Labs has for Envoy is to be able to generate a response header that contains information about the upstream host that was selected. In particular, when subset load balancing is enabled in conjunction with weighted clusters, we want to use a response header to determine which version a host reports and send subsequent requests back to the same subset (via a different route).

I propose to do the refactoring mentioned in resp_header_parser.cc and provide a syntax for selecting host metadata from AccessLog::RequestInfo::upstreamHost. Something like %HOST_METADATA("namespace", "key")% (where namespace for my case is "envoy.lb" and key might be "version"). I think it's reasonable to allow an arbitrary number of keys (e.g. %HOST_METADATA("namspace", "k1", "k2", "k3")% to handle nested structs. I think we should avoid using a syntax like %HOST_METADATA(namespace.k1.k2)% since the namespaces already have periods in them. Beyond that, I'm not tied to the proposed syntax. If someone has a simpler idea, I'm all ears.

An open question for me is how to handle metadata values that are not primitive types. One possibility is that only string/number/boolean can be rendered in headers. That sufficient for our use case, and I lean towards doing just that. Other possibilities include converting lists into appended headers. That gets confusing when the response header is configured not to append. Finally, if the selected value is a struct or list we could render it as JSON, but that seems like a bit much for HTTP headers and is probably slow to boot.