Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

de-capitalizing headers produces server errors with some backends #28

Open
bradgearon opened this issue Aug 11, 2014 · 4 comments
Open

Comments

@bradgearon
Copy link
Contributor

suggestion is to use title case or not modify headers that have been set
does this seem plausible?

@greim
Copy link
Owner

greim commented Aug 12, 2014

Node's http module translates incoming header names to lowercase. nodejs/node-v0.x-archive#1954

So we're stuck with this behavior under node v0.10 but apparently, coming versions will provide a rawHeaders property which should allow Hoxy to pass header names unmodified. I'll leave this open for now and at some point need to ensure tests pass on bleeding-edge node, then can address this issue. (At which point the fix will entail using node v0.11.x or higher)

@sholladay
Copy link
Contributor

Node 0.12.0 is out and support for this is now possible, for anyone willing to implement it.
https://nodejs.org/api/http.html#http_message_rawheaders

When doing so, I would personally appreciate making it configurable, since this is spec breaking behavior.

@greim
Copy link
Owner

greim commented Mar 17, 2015

@sholladay - As long as headerReceived.toLowerCase() === headerSent.toLowerCase() would it be spec-breaking? I probably need to read up on the nuances but was under the impression headers were case insensitive, e.g. CoNtEnT-TyPe would be spec-valid (although not probably handled well by some servers in the wild).

@sholladay
Copy link
Contributor

Correct. What I mean to say is that needing this as a feature is effectively spec-breaking, as it shows you are failing to NOT care about the casing of headers. But I do like choices and for a proxy in particular, it makes sense to be as transparent as possible unless otherwise desired.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants