[vite-plugin] Non-101 WebSocket upgrade responses are destroyed instead of delivered to the client in dev

[colinchadwick]

What versions & operating system are you using?

System:
OS: macOS 26.5.2
CPU: (10) arm64 Apple M4
Memory: 114.05 MB / 16.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 24.12.0
npm: 11.6.2
bun: 1.3.14
npmPackages:
@cloudflare/vite-plugin: ^1.52.0 => 1.52.0
wrangler: ^4.122.0 => 4.122.0

Please provide a link to a minimal reproduction

https://github.com/colinchadwick/vite-plugin-ws-rejection-repro

Describe the Bug

In dev mode, when a Worker responds to a WebSocket upgrade request with a non-101 HTTP response (e.g. 401 to reject an unauthenticated upgrade), the client socket is destroyed without any HTTP response — the client never receives the status code. This breaks native WebSocket clients that rely on the status to distinguish "rejected — refresh and retry" from a network failure.

Rejecting a WebSocket upgrade with a normal HTTP status is the standard RFC 6455 mechanism. RFC 6455 §4.1:

If the status code received from the server is not 101, the client handles the response per HTTP [RFC2616] procedures. In particular, the client might perform authentication if it receives a 401 status code...

Steps to reproduce:

1. npm install
2. npm run dev
3. npm run client (sends a WS upgrade request to a Worker that responds 401 without upgrading)

Expected — the Worker's 401 response is delivered on the upgrade request:

RECEIVED RESPONSE:
HTTP 401 Unauthorized
Content-Type: text/plain;charset=UTF-8
...
rejected: unauthorized

Actual — the connection is destroyed with no bytes delivered.

Root cause — packages/vite-plugin-cloudflare/src/websockets.ts (handleWebSocket):

const workerWebSocket = response.webSocket;
if (!workerWebSocket) {
	socket.destroy();
	return;
}

There is no code path that writes a non-101 response back to the client; the relay only supports 101-with-webSocket or destroy.

Please provide any relevant error logs

CONNECTION DESTROYED, NO HTTP RESPONSE: socket hang up

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #15170

Summary

In @cloudflare/vite-plugin dev mode, a Worker that rejects a WebSocket upgrade with a non-101 HTTP response (e.g. 401) has its client socket destroyed with no bytes written, so the client never receives the status code.

Classification

• Type: Bug
• Component: packages/vite-plugin-cloudflare
• Severity: Medium
• Has Reproduction: Yes (with link) — https://github.com/colinchadwick/vite-plugin-ws-rejection-repro
• Quality: Complete

Findings

• Created: not available (truncated in context.json)
• Author: colinchadwick (Colin Chadwick)
• Version: @cloudflare/vite-plugin 1.52.0, wrangler 4.122.0 (Node 24.12.0, macOS 26.5.2 arm64)
• Labels: not available (truncated in context.json)
• Comments: not available (truncated in context.json)

Analysis

• Component identification: The report is explicitly about @cloudflare/vite-plugin dev mode, and the reporter points to packages/vite-plugin-cloudflare/src/websockets.ts (handleWebSocket) as the root cause. This maps cleanly to packages/vite-plugin-cloudflare.
• Reproducibility: A minimal reproduction repo is provided with clear three-step instructions (npm install, npm run dev, npm run client), plus explicit expected vs actual output. This is a high-quality, verifiable bug report.
• Root cause pinpointed: The reporter identifies the exact code path — when response.webSocket is falsy the socket is destroy()ed without writing the Worker's non-101 HTTP response back to the client. This is a plausible and specific diagnosis.
• Correctness argument: Rejecting a WS upgrade with a normal HTTP status (e.g. 401) is the standard RFC 6455 §4.1 mechanism, so the current behavior diverges from spec and from production behavior. This strengthens the case that it is a genuine bug rather than expected behavior.
• Severity: Medium — it affects a specific but legitimate scenario (auth-gated WebSocket upgrades) in local dev only; it is not a crash or data loss, and a production deploy would behave correctly. Native WebSocket clients relying on the status cannot distinguish rejection from network failure during local development.
• Note: The pre-fetched context.json body is truncated at ~2000 characters, so labels, comment content, created/updated dates, and issue state were not available for this triage. The recommendation is based on the (complete) bug description and reproduction.

Recommendation

Status: KEEP OPEN

Reasoning: This is a complete, well-scoped bug report with a minimal reproduction, version info, and a specific root-cause diagnosis in packages/vite-plugin-cloudflare/src/websockets.ts. The behavior contradicts RFC 6455 and likely differs from deployed behavior, so it is a genuine dev-mode bug worth fixing.

Action: Verify the reproduction against the latest @cloudflare/vite-plugin, then fix handleWebSocket so that when response.webSocket is absent, the Worker's HTTP status/headers/body are written back to the upgrade socket before closing, instead of calling socket.destroy() unconditionally.

Suggested Labels: none applied — repo label set was not available in the truncated context.json; omitting to avoid guessing.

Suggested Comment

Thanks for the detailed report and the minimal reproduction — this is really helpful. You're right that rejecting a WebSocket upgrade with a non-101 status (e.g. 401) is the standard RFC 6455 mechanism, and destroying the socket without forwarding the Worker's response is a bug in the Vite plugin's dev-mode WebSocket handling. We'll look into updating handleWebSocket so the non-101 response is written back to the client before the socket closes. We'll follow up here once we have a fix or need any more info.

Structured summary (JSON)

{
  "issueNumber": 15170,
  "title": "Vite plugin dev mode destroys WebSocket upgrade socket instead of returning non-101 HTTP response",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15170",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Complete, reproducible bug report with a pinpointed root cause in packages/vite-plugin-cloudflare/src/websockets.ts where a non-101 WebSocket upgrade response is discarded and the socket is destroyed. The behavior contradicts RFC 6455 and differs from production.",
  "suggestedAction": "Verify the reproduction against the latest @cloudflare/vite-plugin, then fix handleWebSocket to write the Worker's HTTP status/headers/body back to the upgrade socket when response.webSocket is absent instead of calling socket.destroy().",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ✅ Successfully reproduced. Test confirmed: when a Worker returns a 401 (no webSocket) to a WS upgrade request, handleWebSocket calls socket.destroy() and the client receives zero bytes instead of the HTTP/1.1 401 response.

[quantizor]

A related path never reaches !response.webSocket: when the Worker throws on the upgrade, miniflare.dispatchFetch can reject (gzipped ERROR_STACK JSON parse: #15198) before returning a Response. On vite-plugin 1.43.0 that unhandled rejection kills the process; on current main #14862 catches it and socket.destroy()s, so the client still gets no status, same as this issue.

#15199

[quantizor]

Adjacent, not a fix for this issue: #15201 drops Accept-Encoding on the upgrade dispatchFetch so a throwing Worker is less likely to crash the parse. Non-101 responses are still socket.destroy()d here.