changeOrigin:true changes Host header but not Origin header

Abierto
  • ¿Algo no está bien?
#1,669 0 comentarios 5 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
javascript, nodejs
Área
backend, networking

Línea de trabajo

Compara el manejo actual de changeOrigin en lib/node-http-proxy/http-proxy.js con la implementación de v0.10.4 y PR #723. Comprueba el comportamiento del proxy WebSocket descrito en el issue y determina después si cambiar Origin junto con Host es intencionado, y documenta o prueba el comportamiento resultante.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
JavaScript
Estrellas
14.1k
Forks
2k
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de http-party/node-http-proxy

Todos los issues de http-party/node-http-proxy

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.