Forwarded Origin header not updated on proxied WebSocket requests

[johnhunter]

Describe the bug

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.

The Vite proxy is intended as a convenience for local development rather than use in production. I therefore think Vite proxy should support it out-of-the-box.

I don't have a reproduction I can share but have been able to verify that upstream socket servers that implement RFC-6455 return a 403 and this causes the Vite proxy to error on initial connection.

I'm happy to raise a PR.

Reproduction

n/a

Steps to reproduce

With a vite project that connects to a remote RFC-6455 compliant websocket server without using CORS.

Steps:

1. In vite.config.ts set a ws proxy that points to the websocket server
2. Run npm start
3. Open browser dev tools > network

Expected:

ws request responds with a 101 Upgrade and the socket is established

Actual:

ws request receives no response and its status is Finished

System Info

System:
    OS: macOS 14.4.1
    CPU: (8) arm64 Apple M2
    Memory: 64.20 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.19.1
    npm: 10.2.4
  Browsers:
    Chrome: 124.0.6367.93
  npmPackages:
    @vitejs/plugin-react: ^4.2.1 => 4.2.1 
    vite: ^5.2.10 => 5.2.10

Used Package Manager

npm

Logs

Click to expand!

> vite -d proxy --port 1693
  VITE v5.2.10  ready in 108 ms

  ➜  Local:   http://localhost:1693/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

  vite:proxy /ws -> ws https://proxied.dev.server +63ms
5:50:22 PM [vite] ws proxy socket error:
Error: read ECONNRESET
    at TCP.onStreamRead (node:internal/stream_base_commons:217:20)

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sapphi-red]

I think changeOrigin: true is what you are looking for.

export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:4567',
        changeOrigin: true,
        ws: true,
      },
    },
  },
}

[johnhunter]

Thanks @sapphi-red. changeOrigin: true was set in vite.config and that worked for http proxying but had no effect on ws proxying.

I'll re-check that and confirm.

[johnhunter]

So it looks like changeOrigin is passed in opts to http-proxy's createProxyServer. I would expect http-proxy to apply the origin change (maybe here) but it doesn't appear to.

I'll put the PR to draft while I dig into why http-proxy does not change the origin

[johnhunter]

Ok. changeOrigin does not do what we might think it does - see chimurai/http-proxy-middleware#141 and http-party/node-http-proxy#1130. There's an argument for http-proxy changing or renaming that setting but since Vite passes it straight through I think we should not attempt to conflate the changeOrigin setting with changing the Origin header (as counterintuitive as that seems).

I'll add a clarifying documentation change to my PR when I get a chance and un-draft.