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
Browserify fails to resolve the "./http-proxy/" as "./http-proxy/index.js" but as "./http-proxy.js" (so nothing works)
Beeing explicit here does not cost much for http-proxy, yet it's intrinsically complicated for browserify to fix (as trailing slash might be used as a pollyfill shim for native/non-natives addons i.e. require('url/') vs require('url') )
http-proxy provides a [proxyTimeout option](https://github.com/nodejitsu/node-http-proxy/blob/master/lib/http-proxy/passes/web-incoming.js#L122) that allows us to set a timeout on the outgoing socket connection to the target. This timeout is very effective when the upstream target does not respond within an expected time.
I had wasted a few hours searching for this option. Documenting this option can save others a significant amount of time.
