* Skip sending the proxyReq event when the expect header is present
* Adjust padding to match advisory
Co-authored-by: Smylnycky, Jason M <jason.smylnycky@cengage.com>
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.
While using secure: true for proxy connections, there is no way to pass the trusted root CA(s) or intermediate CA(s). This change allows that to be passed in the httpProxy createServer options and used for the outgoing proxy connection.
* 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.
