HTTP headers are being converted to lower case by http.js

[andrerod]

It seems that all the HTTP headers are being converted to lower case by http.js. This seems incorrect as some apps would want to get the headers with casing as the protocol allows.

Example header as returned from an HTTP server:

Transfer-Encoding: chunked
Last-Modified: Thu, 27 Oct 2011 17:58:43 GMT
x-ms-meta-MyAwesomeField: hi
Date: Thu, 27 Oct 2011 17:58:43 GMT

Example header returned from http.js:

headers:
{ 'transfer-encoding': 'chunked',
'last-modified': 'Thu, 27 Oct 2011 18:10:19 GMT',
'x-ms-meta-myawesomefield: 'hi',
date: 'Thu, 27 Oct 2011 18:10:19 GMT' } }

[c4milo]

http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html section 4.2 says they are case-insensitive

[andrerod]

True. For comparison purposes. That means that when i write a comparison i should ignore casing. However, if I am retrieving them, i should get my casing as it comes down the pipe and as they are stored.

[c4milo]

the thing is that since you need to operate on them and they are case-insensitive you need to either upper or lower case them. The latter is the case of nodejs. Someone as to do it, in this case nodejs is saving you that step IMO. Also applications shouldn't rely in the case of those fields since, again, they are case-insensitive.

[andrerod]

Agree. However it is "destroying" data in-between. I'm trying to figure out if there is a way to access the raw thing...

[c4milo]

what do you mean by "destroying"? aren't you getting headers that you defined? are you getting them incomplete? if this is the case, then there is an issue with nodejs.

[andrerod]

By destroying I mean loosing the casing which is part of the information the server preserves and http.js destroys for the purpose of JS convinience.

[andrerod]

An idea would be to have an option which would tell http.js whether or not we intend that behavior (lowercasing when adding the property to the headers object).

And lowercasing could be the default as indeed for most purposes is more predictable...

[c4milo]

hmm I see, as I said, since the specification says that those names are case-insensitive, any application that relies in the case of those fields and doesn't normalize them, before use them, has an issue. Meaning that nodejs is not the problem. This is just my opinion, @ry or @mikeal might have another opinion.

[felixge]

By destroying I mean loosing the casing which is part of the information the server preserves and http.js destroys for the purpose of JS convinience.

Protocol artifacts are not information. By the same logic you could argue that you want to receive the message body without chunked-encoding handled for you.

If your app really requires either of those, use the net module and parse things yourself. Node should not support non-standard http semantics beyond of what may be necessary to deal with broken clients/servers that have widespread usage.

[andrerod]

Fair enough...

[mikeal]

you may also want to check out substacks recent pure-js HTTP parser.

https://github.com/substack/node-parsley

[bnoordhuis]

I suppose we could make the raw headers available for people that want them. The C++ binding passes them as-is to JS land so the mechanism is already in place.

I've wanted it myself from time to time for Set-Cookie and Authorization headers (IIS + NTLM often sends two of those).

[stiang]

Sometimes you actually need the raw headers as returned by the remote server, so I strongly support letting those who want them have access to them.

For example, I’m building a proxy service that relays requests and gives you access to the request and the response (including headers) in a web interface, but as it stands now I cannot show the actual headers received from the remote server, just the lowercased version. This is unfortunate, since the service should show exactly what the client would receive. And it seems silly to have to implement my own http module just because of this.

How should the raw headers be made available, if you decide to support it? As response.rawHeaders or something like that? I might try to cook up a PR if I knew what to implement.

[isaacs]

This issue is over a year old and I don't think it's a great idea to revive it. I'm ok with providing access to the raw header string in 0.12, but we're going to keep lowercasing the req.headers object, because it's useful for many much more common use cases.

Please open a new issue and we can sketch some API ideas. I think a rawHeader field had been discussed in the past.

[rodrigoalvesvieira]

👍 for the patch. The access to the original, unmodified header can be really useful sometimes and a property only for it would be great.

[ghost]

I'm curious what the use case is for "raw" headers since the case of the text is meaningless (contains no information). Because the case is meaningless, conversion to a uniform case simplifies the code that inspects them, so there's a material benefit to lower casing them.

"Sometimes you actually need the raw headers as returned by the remote server"

Example? Just one.

[franck-eyraud]

One example : Proxy.
If, as I was developing, you are proxying between a client and a server (two couchdb instances replicating in that case) for which case is important (it is probably wrong, but you can't modify the code) : the client didn't understand the answer if the headers' case was not the original one. In that case, you need to forward headers exactly as received.

[ghost]

That example imposes a constraint on the server (leave headers as-is) that does not exist in the specification, with the stated purpose of interoperating with systems that violate the specification. Granted, nothing says you cannot leave them as-is but it's more convenient to convert them once.

[tomasdev]

Thank you @asah :D - sadly some browsers (ehem) do not understand lowercase headers

[cwharris]

This is a blocker for me. I am working with a finicky server that is expecting UserAgent and Accept headers, and will throw if the header casing does not match exactly.

Is there a reason the headers are being mutated, or can an ordinal comparison solve this instead of mutating parameters the user has set explicitly?

[Fishrock123]

Related to nodejs/node#3591

If you care about this I suggest opening an issue on https://github.com/nodejs/node