changeOrigin:true changes Host header but not Origin header
还没有人认领这个 Issue。
评估
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 新手友好度
- 30/100
- Issue 类型
- 缺陷
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- javascript, nodejs
- 领域
- backend, networking
调研方向
将 lib/node-http-proxy/http-proxy.js 中当前对 changeOrigin 的处理与 v0.10.4 的实现以及 PR #723 进行比较。检查 issue 中描述的 WebSocket 代理行为，然后确定是否有意在更改 Host 的同时更改 Origin，并记录或测试由此产生的行为。
由索引模型根据 Issue 内容生成。
描述
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:
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. https://github.com/http-party/node-http-proxy/pull/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.
- 主要语言
- JavaScript
- 星标
- 14.1k
- 派生
- 2k
- PR 合并指标
- 30 天内没有已合并 PR
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
http-party/node-http-proxy 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
http-party/node-http-proxy#1719 ·
-
难度 3/5 1-2 天 新手友好度 72/100
http-party/node-http-proxy#1721 · 1 条评论 ·
-
难度 1/5 1 小时以内 新手友好度 55/100
http-party/node-http-proxy#1715 · 1 条评论 · 5 个 reaction ·
-
难度 1/5 1 小时以内 新手友好度 15/100
http-party/node-http-proxy#1711 · 2 条评论 ·
-
难度 5/5 一周以上 新手友好度 25/100
http-party/node-http-proxy#1710 · 5 个 reaction ·
查看 http-party/node-http-proxy 的全部 Issue
相似的 Issue
-
bug needs-triage potential-regression
难度 2/5 1-3 小时 新手友好度 78/100
aws/aws-sdk-js-v3#8408 ·
维护者通常 1 天内回复
-
[v3] KeyBindingManager calls (Add/Remove) are not converted into a case-insensitive accelerator.Key未关闭Bug
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 4 天内回复
-
fix(docs): align git__gh troubleshooting with its actual failure paths可能已有人在做 @akhil9tiet 今天认领。 未关闭bug docs p2
难度 1/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100