Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Forwarded Origin header not updated on proxied WebSocket requests #16557

Closed
7 tasks done
johnhunter opened this issue Apr 29, 2024 · 4 comments · Fixed by #16558
Closed
7 tasks done

Forwarded Origin header not updated on proxied WebSocket requests #16557

johnhunter opened this issue Apr 29, 2024 · 4 comments · Fixed by #16558
Labels
has workaround p2-edge-case Bug, but has workaround or limited in scope (priority)

Comments

@johnhunter
Copy link
Contributor

johnhunter commented Apr 29, 2024

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

@sapphi-red
Copy link
Member

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
Copy link
Contributor Author

johnhunter commented Apr 30, 2024

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
Copy link
Contributor Author

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
Copy link
Contributor Author

johnhunter commented Apr 30, 2024

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.

@sapphi-red sapphi-red added has workaround p2-edge-case Bug, but has workaround or limited in scope (priority) labels May 16, 2024
@github-actions github-actions bot locked and limited conversation to collaborators Jun 14, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
has workaround p2-edge-case Bug, but has workaround or limited in scope (priority)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants