HTTP headers case gets modified

[maguec]

When sending a custom header through traefik, it gets recased causing the application to fail.

Is there a way to disable any re-casing?

Repro step:
curl using a cusom header

curl -H "X-tEST-hEADER: true" -o /dev/null -v http://backend.example

TCPDUMP on the other side to see

X-Forwarded-For: <REDACTED>
X-Forwarded-Host: <READACTED>:31880
X-Forwarded-Proto: http
X-Forwarded-Server: qatcd-haproxy-1
X-Test-Header: true
X-Traefik-Reqid: 153670
Accept-Encoding: gzip

Note this happens on the way back as well if I set a header in all caps it comes back camel-cased

[emilevauge]

Hi,
From RFC 2616 - "Hypertext Transfer Protocol -- HTTP/1.1", Section 4.2, "Message Headers":

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

golang std library transforms them in a canonical way golang/go#5022.
I strongly recommend you to make your apps case insensitive too.

[maguec]

Thank you for the amazingly quick response.
It is greatly appreciated.

Unfortunately this is not an option at this time for these legacy applications.
Keep up the awesome product

[emilevauge]

Reopening this old issue, as we might discuss a way to disable this behavior.

[dtomcej]

There is the classic way to dodge this behavior, by setting headers via map, so the key case is preserved ;) its old, and may not work forever, but it is doable 😝

[cmullendore]

Copied from my own comment at #466 (comment) :

1. It is not the responsibility of Go or any other language/platform to unilaterally decide how other systems should behave, including whether or not the systems being interacted with follow the case-insensitivity statement of the RFC.
2. A system/platform should not modify the information it is handling unless modification is the direct purpose of the request.
3. The code used to modify the casing of field names likely introduces unnecessary functionality that risks additional bugs (regardless of whether such bugs currently exist) and removing that (and in fact any) such code eliminates the risk that such code could introduce unintended behavior.
4. If the supposition that uses of the platform really are respecting the case-insensitivity nature of the current implementation and therefore the current behavior of case modification theoretically introduces no issues, then removing this behavior should also cause equally zero impact to users.
5. Removing this functionality provides platform users with the opportunity to pre-conform to HTTP/2 casing standards if they so choose, per https://tools.ietf.org/html/rfc7540:

A malformed request or response is one that is an otherwise valid
sequence of HTTP/2 frames but is invalid due to the presence of
extraneous frames, prohibited header fields, the absence of mandatory
header fields, or the inclusion of uppercase header field names.

There is literally no reason for modification of this behavior to be resisted by this team.

[acejam]

@emilevauge Are there any updates on this issue? I unfortunately can no longer use Traefik due to the header casing manipulation. (Regardless of what the RFC says)

[emericv]

I have the same issue too with a client that cannot be modified due a critical environment!

[JohnRusk]

-previous comment deleted. Logged in wrong project-

But I totally agree about header preservation!

[ldez]

Small reminder:

• HTTP/2 RFC7540

Just as in HTTP/1.x, header field names are strings of ASCII
characters that are compared in a case-insensitive fashion. However,
header field names MUST be converted to lowercase prior to their
encoding in HTTP/2.

• HTTP/1.0 RFC2616

Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

• Golang related issues:
  • net/http: allow control of case of header key golang/go#5022
  • net/http: CanonicalHeaderKey capitalization is non-conformant with RFC 6455 golang/go#18495
  • Canonical form of 'ETag' header is incorrect golang/go#18476
  • net/http/httputil: ReverseProxyHeader doesn't preserve header key case golang/go#18196
  • ...

[JohnRusk]

Field names are case-insensitive.

Yes, but unfortunately, this is one of those areas where "what the standard says" and "what many people have come to rely on" are not the same thing.

[acejam]

Bump for updates. We can no longer use Traefik due to this issue.

[JohnRusk]

Feel free to also comment here: golang/go#37834

It's a thread to ask the Go team to either offer a workaround, or accept one developed by the community. Hopefully, if there's enough activity on that thread, they'll say yes ;-)

FYI, I'm not aware of any other viable answer to the problem.

[gufertum]

Please do not modify headers that pass through a proxy - this is bad-by-design. It should be transparent.

[milankowww]

one more use case for you for not doing unnecessary conversions: old Outlook clients can't talk to Exchange via Traefik; only newest ones work

[ddtmachado]

Thanks for everyone that participated in the discussions so far. As of now, we are not going to change the way we handle headers. We've put a lot of thought into it and here is why we think this is the right decision:

• We think the use-case for case-sensitive headers is going to become increasingly smaller as headers must be case-insensitive according to the HTTP RFC and HTTP/2 doesn't change that. Therefore, trying to adapt to this will bring more code complexity. Even worse, we believe that changing has the potential to introduce unintended behavior that would affect most/all users.
• Traefik Proxy was never meant to be a transparent proxy, and we have no plans of becoming one, so that solution is not going to work for us as well.
• If Go chooses to provide a solution in the future, we should follow it, but we just don't think they will do so.
• Finally, an App that uses case-sensitive has always been broken and needs to be fixed sooner or later.

We are going to close this issue, should Go provide a solution, please feel free to open a new one.