This ticket continues the various discussions that have happened over the years on the topic of header casing in HTTP/1.1

In short, while the spec does not require header casing to be preserved, many legacy applications were written to assume the casing of HTTP headers and may be hard or impossible for some organizations to fix.

I will (soon) be preparing a design doc for this feature. The high-level idea is that we might be able to modify the HTTP1 codec to be aware of the original header casing observed from either downstream clients (when forwarding headers upstream) or from upstream servers (when sending headers downstream) and use that context to format headers, perhaps re-using the existing HttpHeaderFormatter.

As additional context, to support a much simpler use case, I wrote gravitee-io#9 to force (not preserve) header casing on certain configured header keys. This was relatively straight-forward because forcing header values on a fixed set of keys doesn't require complex context to be passed around. Ideally this solution could be replaced by a more comprehensive solution that we come up with here.

Continues: #8463

cc @mattklein123 @snowp