Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Header key 'host' should be 'Host' #411

durango opened this Issue Jan 10, 2013 · 16 comments


None yet
6 participants

durango commented Jan 10, 2013

Some servers, such as FedEx's API servers, actually care about this case sensitivity.

From RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1", §4.2, "Message Headers":
Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive.

You'll also note, pretty much every other header in the library is lower case... 'set-cookie', 'authorization', 'content-length', 'content-type', etc.

I think perhaps you could ask for a new 'compatibility' feature which would capitalize the first letter of all field names fed into the underlying http(s) library. But it's incorrect to say 'host' should be 'Host'.

There are some places where the lib checks for a header set with the first letter capitalized, but it seems inconsistent:

// checks for both...
if(!self.headers['content-length'] && !self.headers['Content-Length'])
self.headers['content-length'] = length


// checks for lower case only
if (self.proxy && self.proxy.auth && !self.headers['proxy-authorization'] && !self.tunnel) {


mikeal commented Jan 11, 2013

yeah, fedex is broken, BUT, we need to move header checks to be caseless. either getHeader or checkHeader method that performs caseless. i see there is a new issue created for that so i'm going to close this one.

I wouldn't close the issue - two different problems I think:

  1. inconsistent setting/checking of headers with and without capitalization in self.headers
  2. ability to specify [certain?] headers should be sent over the wire capitalized for compatibility purposes

I guess the 'two birds one stone' way would be if it's capitalized in the data structure it goes over the wire capitalized, and then if all internal checks are case-insensitive... would that give enough freedom to the end user to ensure headers they want to be capitalized actually make it out that way?


mikeal commented Jan 11, 2013

by default, request will continue to set headers capitalized.

once we make the header checks caseless you can pass the header yourself in the case you prefer and we won't conflict or reset it.

durango commented Jan 12, 2013

@jspilman yup I'm well aware that it should be case insensitive, but like I said, whatever FedEx's servers are using (Apache?) it does care about casing.

@mikeal So does this mean host will become Host (since you said by default headers will be capitalized)? Would be very interested in having the option to overwrite if not :)


mikeal commented Jan 12, 2013

i'm pretty sure Apache doesn't break HTTP :)

i actually mistyped that, they will NOT be capitalized. the option to overwrite it will just be {headers:{'Host':'fedex.com'}} and because the new header check will be caseless it won't overwrite it or conflict with it.

durango commented Jan 12, 2013

Alright thanks, I'll cotninue watching this issue for a git commit :) Appreciate it 👍

aseemk commented Feb 24, 2013

Nice proposed solution, @mikeal. 👍

I'm on 2.9.203 and I just wasted a good bit of time with this issue. I was trying to set the header capitalized, but it wasn't working at all. So yeah, if you want to use the 'host' header, it seems like you really must lowercase it!


mikeal commented Jun 9, 2014

If you set the host header capitalized it should be capitalized, it just isn't by default. If that is not the same then it's a bug.

What I meant, was that I think that the header was getting overwritten or not accepted by the server I was making the request to. Apache for one, was not accepting the 'host' header if I capitalized it. It just seems to have missed the header completely.


mikeal commented Jun 10, 2014

Really? Apache? That's a gross violation of the http spec.


mikeal commented Aug 27, 2014

this has come up a bunch, we aren't changing the default, but caseless handling is much better now.

@mikeal mikeal closed this Aug 27, 2014

obender commented Jun 1, 2016

We have same issue vs the content-length, Apache Tomcat HTTPD lib refses to accept the low capital header... content-length its' allowing in Content-length only...


mikeal commented Jun 1, 2016

The standard in Node.js is lowercase. In fact, core http automatically lowers headers in the server.

Apache Tomcat HTTPD is violating the HTTP spec which explicitly states that headers are caseless. We do a lot of work in request to ensure we are caseless, I even wrote this entire dependency just to deal with it https://www.npmjs.com/package/caseless :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment