changeOrigin:true changes Host header but not Origin header

[johnhunter]

This issue has come up in Vite, which delegates proxying to http-proxy.

When Proxying to a WebSocket service in local development the socket connection can rejected by the server as the Host and Origin header values do not match. This Origin-limiting behaviour is recommended in RFC 6455 and is implemented in the Java websockets API and the Gorillas websocket package.

I looked though http-proxy source code to understand the changeOrigin option. It seems that the option originally did set both Host and Origin headers to match the target, e.g. in version v0.10.4:

https://github.com/http-party/node-http-proxy/blob/v0.10.4/lib/node-http-proxy/http-proxy.js#L675-L678

A subsequent refactoring for v1.0.0 did not include the setting as far as I can tell. A PR then reinstated the changeOrigin option where it conditionally changes the Host header but not the Origin header. #723

So I'm interested to know if dropping the change to the Origin header was for a specific reason, or if it just got missed in the v1.0.0 refactor?

The name "changeOrigin" can be confusing but reflects the terms used the HTTP/1.1 RFC-7230 (Jun 2014). It is notable that the RFC does not mention an Origin header. The Origin header is typically only included in cross-origin requests or same-origin requests other than GET / OPTIONS as defined in RFC-6454 (Dec 2011). I believe the confusion arises from the use of “origin” to mean the originator of a request, and the specific request header. However, it seems reasonable to expect that an option changeOrigin:true would change the Origin header, even if it also changes the Host value.

I can raise a PR to reinstate the Origin change but I'm not clear if there are good reasons not to do so. Given there are quite a few open PRs I'm not confident that project maintainers are in a position to review, merge and release any changes.

Happy to hear any thoughts for or against reinstating the behaviour.