expose httpConnectionManager.http_protocol_options.header_key_format Gloo API

[bdecoste]

Requirement is to preserve the case of response headers. Assume this should be added to httpGateway.options.httpConnectionManagerSettings

[ashleywang1]

The envoy ProperCaseWords HeaderKeyFormat: https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/core/protocol.proto#envoy-api-msg-core-http1protocoloptions-headerkeyformat

Formats the header by proper casing words: the first character and any character following a special character will be capitalized if it’s an alpha character. For example, “content-type” becomes “Content-Type”, and “foo$b#$are” becomes “Foo$B#$Are”. Note that while this results in most headers following conventional casing, certain headers are not covered. For example, the “TE” header will be formatted as “Te”.

There is no option to preserve the case of the response headers if they look like: cONtent-tYpe.

If that is the case, based on the envoy issue here: envoyproxy/envoy#8463, it is unlikely that we'll be able to upstream an envoy change that exactly preserves the header case formatting from the upstream. The general consensus from the envoy devs is that "even the non-intrusive version IMO is going to be hairy to survive H2 hops, header additions and header removals."
So our options here best case to worst case scenarios:

• Discover that all the "standard response headers that is sent by the provider" are actually Proper Case anyway, in which case my PR will be sufficient.
• Discover that all the "standard response headers" have another fixed / known format e.g. TrainCase. In this case, it is more likely that we can upstream an envoy change, and then exposing it in Gloo is also easy.
• If their headers are really, absolutely broken and the case needs to be preserved, then we'll have to consult some subject matter experts and figure out if this is even feasible to do with Gloo and Envoy.

[bdecoste]

This may also be applicable: envoyproxy/envoy#8463