Skip to content
This repository has been archived by the owner. It is now read-only.

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

Closed
andrerod opened this issue Oct 27, 2011 · 25 comments

Comments

@andrerod
Copy link

commented Oct 27, 2011

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

This comment has been minimized.

Copy link

commented Oct 27, 2011

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

@andrerod

This comment has been minimized.

Copy link
Author

commented Oct 27, 2011

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

This comment has been minimized.

Copy link

commented Oct 27, 2011

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

This comment has been minimized.

Copy link
Author

commented Oct 27, 2011

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

This comment has been minimized.

Copy link

commented Oct 27, 2011

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

This comment has been minimized.

Copy link
Author

commented Oct 27, 2011

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

This comment has been minimized.

Copy link
Author

commented Oct 27, 2011

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

This comment has been minimized.

Copy link

commented Oct 27, 2011

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

This comment has been minimized.

Copy link

commented Oct 28, 2011

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.

@felixge felixge closed this Oct 28, 2011

@andrerod

This comment has been minimized.

Copy link
Author

commented Oct 28, 2011

Fair enough...

@mikeal

This comment has been minimized.

Copy link

commented Oct 28, 2011

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

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

@bnoordhuis

This comment has been minimized.

Copy link
Member

commented Oct 28, 2011

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

This comment has been minimized.

Copy link

commented Feb 24, 2013

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 comment has been minimized.

Copy link

commented Feb 25, 2013

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

This comment has been minimized.

Copy link

commented Feb 26, 2013

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

franck-eyraud added a commit to franck-eyraud/AAAforREST that referenced this issue May 19, 2014

FIX: Convert headers in first-letter Capitalize.
To work with CouchDB replication and node.js version < 0.11.6.
Because of [this issue](nodejs/node-v0.x-archive#1954) fixed [here](nodejs/node-v0.x-archive@e6c81bd)
@ghost

This comment has been minimized.

Copy link

commented Sep 15, 2014

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

This comment has been minimized.

Copy link

commented Sep 16, 2014

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

This comment has been minimized.

Copy link

commented Sep 16, 2014

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.

@swick7

This comment has been minimized.

Copy link

commented Oct 8, 2015

I have a case where I have a nodejs/express route that simply pipes the request for an image from a web browser to a destination server on a different domain and pipes the response back to the web browser. It works fine locally, but when I deploy the application to an IIS server, I get a 502 Bad Gateway response. Changing the "host" header in the response to "Host" fixes the problem. The http/request module is changing the header to lowercase, an as a result, I have to use 20 lines of code to prevent this from happening instead of just one line of code. It's a bummer. Wish there was some compromise.

@sisyphsu

This comment has been minimized.

Copy link

commented Oct 22, 2015

This is a horrible issue......
Some server(IIS) may not accept lowercase headers and throw exception......
if you meet this case, you will be killed......

@asah

This comment has been minimized.

Copy link

commented Dec 5, 2015

example: I'm trying to proxy requests to Parse mBaas (parse.com) and it appears to care about case-sensitivity. It seems unlikely that Facebook is going to change to support us :-) thanks!

@asah

This comment has been minimized.

Copy link

commented Dec 5, 2015

don't hate. Here's my workaround (warning: JS/Node/Express newb):

function fixup_node_headers(req, res, next) {
    for (oldkey in req.headers) {
        var newkey = oldkey.replace(/((?:^|-)[a-z])/g, function(val) { return val.toUpperCase(); });
        // custom hack for X-Parse-Os-Version ==> X-Parse-OS-Version                                                                                                                 
        newkey = newkey.replace(/(-Os-)/g, function(val) { return val.toUpperCase(); });
        req.headers[newkey] = req.headers[oldkey];
        delete req.headers[oldkey];
    }
    next();
}
@tomasdev

This comment has been minimized.

Copy link

commented Mar 30, 2016

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

@cwharris

This comment has been minimized.

Copy link

commented Dec 13, 2016

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

This comment has been minimized.

Copy link
Member

commented Dec 13, 2016

Related to nodejs/node#3591

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
You can’t perform that action at this time.