HAProxy 2.0.0 header

This morning I upgraded to version 2.0 (from 1.9.8) and a lot of headers arrive lowercase to the backend.
It’s strange, not all headers but let me say 99% (the only one with capital letter is “Connection: close”).

I think this is not correct…am I wrong ?

Hi @scegliau,

You’re right. In H1, this header is not added in lower case. I pushed a fix in upstream and backported it to 2.0 and 1.9. Thanks !

Thankyou so much but the thing that looks strange to me is that all headers, but “Connection”, arrive lowercase to the backend.
Why there’s this sort of manipulation on headers’name ?

In particoular we have some problem with CA Siteminder headers, like SM_USER, and applications which search for a capital name.

Is it right that all headers became lowercase ?

First of all, in HTTP/1, header names are case-insensitive. See https://tools.ietf.org/html/rfc7230#section-3.2. Then, in HTTP/2, all header names must be encoded in lowercase (https://tools.ietf.org/html/rfc7540#section-8.1.2).

So, internally, for convenience and consistency matters, we decided to store them in lowercase. You may be surprised by this conversion because you don’t use HTTP/2. But think about h2 clients sending requests to h1 servers. All headers will be in lowercase. Same is true for h2 servers replying to h1 clients.

If it is a problem for your application, you can disable the HTX format with no option http-use-htx. But note that the old HTTP format (called legacy HTTP) will be removed in HAProxy 2.1. If there are too many complaints about the subject, we will try to address it using a map or something of that taste. Note also, in legacy HTTP, headers are not “capitalized”. So if a client sends a request with a funny case, the problem will be the same for your application.

1 Like

Yes I know that header names are case-insensitive, as per RFC.
The thing I didn’t understand was why you have to manipulate headers’ name and don’t pass them as they are, but now you explained it to me.

So…thankyou very much for explanation and for the patch !!

regards
andrea

Yeah … browser never randomized the case of header names, so HTTP/1.1 applications really did not have to consider that in reality, in fact application developers may have argued that making header matches case-insensitive is expensive and practically not needed.

I assume that a large amount of applications does not consider the header names case-insensitive in HTTP/1.1.

This is report number 1 here, I assume the following issue is due to the same reason:

edit: It’s not, its about an actual 2.0 bug.

We still need to monitor this, but I feel like we will see more of this soon.