changeOrigin:true changes Host header but not Origin header

Đang mở
  • Có gì không ổn?
#1,669 0 bình luận 5 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
30/100
Loại issue
Lỗi
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Đình trệ
Công nghệ
javascript, nodejs
Lĩnh vực
backend, networking

Hướng nghiên cứu

So sánh cách xử lý changeOrigin hiện tại trong lib/node-http-proxy/http-proxy.js với phần triển khai của v0.10.4 và PR #723. Kiểm tra hành vi của WebSocket proxy được mô tả trong issue, sau đó xác định liệu việc thay đổi Origin cùng với Host có phải là chủ đích hay không, và ghi lại hoặc kiểm thử hành vi thu được.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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. 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.

Ngôn ngữ chính
JavaScript
Star
14.1k
Fork
2k
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của http-party/node-http-proxy

Tất cả issue của http-party/node-http-proxy

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.