WC to WC WebSocket connections failing with `400 BadRequest` errors; breaking unit tests, REPLs, server-side CLI tools, multi-process optimizations, Server SB to Client SB use and dependencies

[FossPrime]

Describe the bug

Chat bots, unit tests, DB connections, multi-process optimizations, dependencies and integrations

Describe the bug Trying to connect to a WebSockets server from WebContainers causes a 400 Bad Request error. This happens even when connecting to a Socket.io server hosted in the same WebContainer or other WebContainers in other StackBlitz Sandboxes.

Connecting to WebSockets servers from the browser works normally, as long as CORS is configured. this issue is not about connections from the browser. This issue is exclusively about connecting from WebContainers to WebContainers running WS servers, that is, NOT to external Node.js server. No browser code, baremetal code or external servers are necessary to encounter this issue.

This affects:

• Socket.io and Feathers api tests
• Chatbots prototypes, demos and projects
• Server HMR dev tools like vavite and custom vite server side, for validations, readiness checks and general optimization
• Dependencies and utilities that spawn a new node process to connect to your WS server

Link to the blitz that caused the error

Simplest socket.io example: https://stackblitz.com/edit/sb-ws-bug?file=vite.config.ts,ReadMe.md

Steps to reproduce

2. run this code on SB, aka npm run dev

Expected behavior

All posted "Chatbot" messages will print to the console.

Actual Behavior

• Status code 400 'Bad Request' errors.
• WebContainers unable to connect to self or other WC WebSockets servers running on the same browser session and SB account

Link to the blitz that caused the error

https://stackblitz.com/edit/sb-ws-bug?file=vite.config.ts,ReadMe.md

Steps to reproduce

1. open the sand box and watch the errors pop up every 3 seconds.

Expected behavior

• Connections from WC to WC should work like baremetal
• WS Connections from one Sandbox to another should work like two separate apps running on two different baremetal ports

Parity with Local

• [X] I have run the project in my local machine and I could not reproduce the issue.

Screenshots

From reproduction sandbox:

Same code in bare-metal Node.js:

Platform

• OS: ALL
• Browser: Chrome and Firefox
• Version: 102

Additional context

Workarounds

Current workaround is to run the server baremetal if possible, or host it externally in something like CodeSandbox Containers or Kubernetes.

[d3lm]

Hey there 👋 Just wanted to inform you that WebSocket support has been added for inter-process communication. This means that you can now have a WebSocket client in one process and a server in another process. I tested your provided chat example and it seems to work as expected. I am closing this issue for now. If you still experience issues, feel free to open a new issue.