object.keys in web-incoming.js results in a non-deterministic ordering of keys, which means that in web-outgoing writeHead might be called before setHeader, which throws an error
This PR tries to fix "Can't set headers after they are sent" errors.
That are a lot of situations where this error can occurs. In my case, it is happening because I have others middlewares (in an expressjs application that tries to proxy requests). Some of those middlewares (like [passportjs](http://passportjs.org/), or [cors](https://www.npmjs.com/package/cors)) can run ```res.end()``` and when the proxy receive a response, it is already finished.
So, it is necessary to test if we can write on the user response when the proxy response is ready.
I think it could also fix#930, #1168, #908
When the server do not accept the upgrade request for websockets the
server's response was previously not included and sent back. Now the
proxy will include the response in these cases. Fixes#890.
* Keep original letter case of response header keys
* Support node older than v0.11.6
messege.rawHeaders was added in v0.11.6
* Extract duplicated logic to method
* Fix for Reason-Phrase being overwritten on proxy response.
Calling res.writeHead has the side effect of defaulting the Reason-Phrase to default ones. I'm using Reason-Phrase codes to sub-route api responses and they were all being reset. This change only sets the statusMessage (Reason-Phrase) if it exists on the proxyRes and is successfully passing it through in my tests.
* Fixed spaces and bracket formatting.
* Emit disconnected event instead of error when ECONNRESET
ECONNRESET means the other side of the TCP conversation abruptly
closed its end of the connection.
If we get an ECONNRESET error from the proxy request and the
socket is destroyed this means that the client has closed
his connection, and emit this as an error can lead to
confusion and hacks to filter that kind of message.
I think that the best we can do is abort and emit another event,
so if any caller wants to handle with that kind of error, he can
by listen the disconnected event.
https://github.com/nodejitsu/node-http-proxy/issues/813
* code standards, move econnreset check, change ev name
Reasoning: Rack's request class [makes use of](https://github.com/rack/rack/blob/master/lib/rack/request.rb#L243) this HTTP header. Certain edge-case scenarios (proxying from ember-cli to a Rails backend) can be problematic without this header being present.
/cc @perlun, @jesjos
Set-Cookie headers are parsed into single header with cookies in array.
This messes up the Set-Cookie headers, because browser receives multiple Set-Cookie headers as single with cookies separted with comma.
if functioning as a reverse proxy for host1.foo.com,
with a backend target of backend.foo.com:8080, the
node proxy should only rewrite the redirect if it is
a redirect to somewhere on backend.foo.com:8080
auto host rewriting allows rewriting to work as expected in most
cases without extra cumbersome configuration
protocol rewriting allows node-http-proxy to be able to listen
over HTTPS and properly reverse-proxy to sites running over HTTP
(to avoid doing SSL twice)
Web browsers automatically issue an OPTIONS request in advance of other
HTTP requests when the document's domain does not match the target in
order to facilitate Cross-Origin Resource Sharing. These requests are
forbidden from specifying a body and typically do not specify an
(unecessary) `Length` header.
Node.js automatically adds the `Content-Encoding: chunked` header value
to requests that do not specify a `Length` header. This makes proxied
OPTIONS requests from web browsers invalid.
Explicitly set the `Content-Length` header of all `OPTIONS` requests to
"0", disabling the default "chunked" encoding behavior [2].
[1] http://www.w3.org/TR/cors/
[2] http://nodejs.org/api/http.html
