Different capitalization on Response Headers

(Miguel Callejas) #1

Hi everyone, I’m using Caddy in production and now I have a customer that uses a response header that needs to be “sessionId”. Their application is case sensitive.

I realize that a direct request to the backend, will return:
sessionId: a3688a2d-5b20-4d04

but when the request goes through Caddy, the capitalization changes to:
Sessionid: a3688a2d-5b20-4d04

The definition of my Caddyfile for this backend is:

:80 {
  tls /root/.caddy/wildcard/root.pem /root/.caddy/wildcard/key.pem
  log / stdout "{remote} - {user} [{when}] \"{method} {uri} {proto}\" {status} {size} {latency}"
  errors stderr
  timeouts 2h

  proxy / backend:8080 {
    policy round_robin

Is there any way to preserve or rewrite the response header before is sent to the origin?
I found a lot of information about why Headers should be case-insensitive. But I cannot make the customer change their application because the way they use that header from other backends.

Any thoughts?
Thanks for the support!

(Matt Holt) #2

HTTP headers are case-insensitive; relying on them being case-sensitive is a bug in their application. I know this isn’t what you want to hear, but…

The Go standard library standardizes header names. If their application needs case-sensitivity, it first needs to respect the standards and then it can transform the case to its liking after consuming the header.

(Lucas) #3

It’s also worth mentioning is that with HTTP/2 all header names get converted to lower-case, so while header names are case-insensitive they will be lower cased when using HTTP/2 as a necessary step in the protocol (I assume you’re not using HTTP/2 due to it being on port 80, but if you do move to it then it’s something you would need to deal with anyway).

Here’s an excerpt from the RFC: https://tools.ietf.org/html/rfc7540#section-8.1.2

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. A request or response containing uppercase header field names MUST be treated as malformed (Section