falcon: Falcon should not be changing headers to lower case
Falcon seems to be intentionally changing headers to lowercase as follows:
# NOTE(kgriffs): normalize name by lowercasing it
self._headers[name.lower()] = value
So if I set X-Auth-Token at the server, the client gets x-auth-token.
I’m aware that HTTP headers are case insensitive but even so I think it’s more for the application to deal with that - the server shouldn’t be changing them IMO.
About this issue
- Original URL
- State: open
- Created 9 years ago
- Comments: 26 (17 by maintainers)
P.S. It’s interesting to note that HTTP/2 requires lowercased headers. I suspect it is an acknowledgement that allowing for case insensitivity leads to clients not always doing the right thing, with performance perhaps being a secondary concern (albeit a minor one).
Given that HTTP/2 lowercases all headers anyway, and the protocol is becoming prevalent, is it worth the effort of addressing this after all?
I think we can mitigate much of the potential performance regression in doing this by not going through the mapping interface and just interacting with a standard library
dictdirectly. I’ve prototyped the implementation and it seems to work reasonably well. Scheduling this for Falcon 2.0.“Be conservative in what you do, be liberal in what you accept from others” - I thought this approach is now thought to be a bad way to design software. Better to design systems that are extremely clear on their expectations in and out.
I just noticed Falcon changes headers into lowercase and a quick search got me here.
Although I agree that the HTTP protocol doesn’t require headers to be case senstive and that is a reasonable argument to end dicussion (since it improves performance), I’m also a huge fan of the Robustness principle: “Be conservative in what you do, be liberal in what you accept from others” – and turning the headers lowercase, breaks the non-spoken rule of writing each word with a capital letter, so in that sense, we are not being conservative when we “do”.
I understand there’s an optimization gain when headers are turned into lowercase for comparsion, but I think the suggestion on #420 : “Similar to above, but keep (OriginalCaseName, case_folded_name, value) so that when searching the list we only have to do a case fold on the incoming name, vs. also having to do it on each name already in the list.” might be worth the performance loss (i.e. the developer can send case-senstive headers to be conservative, but have it treated in a “liberal” way when comparing only lowercase strings).