[vite-plugin] WebSocket upgrade forwards Accept-Encoding gzip; Worker throw becomes undici JSON.parse crash

[quantizor]

What versions & operating system are you using?

• macOS (darwin 25.6.0), arm64
• Node v24.11.0
• @cloudflare/vite-plugin 1.43.0
• wrangler 4.107.0
• miniflare 4.20260701.0
• undici 7.28.0

Please provide a link to a minimal reproduction

cloudflare/vinext#2921

Describe the Bug

handleWebSocket (packages/vite-plugin-cloudflare/src/websockets.ts) forwards a browser WebSocket upgrade to miniflare.dispatchFetch with createHeaders(request), which copies every request header, including Accept-Encoding: gzip.

When the Worker throws on that upgrade, workerd returns a 500 JSON error with Content-Encoding: gzip and MF-Experimental-Error-Stack. miniflare's dispatchFetch then calls response.json() without decompressing (DispatchFetchDispatcher does not inflate). That rejects with:

SyntaxError: Unexpected token '\u001f', "\u001f�\b..." is not valid JSON

On 1.43.0 the upgrade listener is async with no try/catch, so the rejection is unhandled and Node exits (exit 7). Vite HMR sockets (sec-websocket-protocol starting with vite) are skipped; Worker sockets are not.

On current main, #14862 wraps dispatchFetch in try/catch and socket.destroy()s. That stops the process death (good) but:

1. The Worker's exception is never revived or logged. The gzip SyntaxError is swallowed.
2. The client still gets no HTTP response. That is [vite-plugin] Non-101 WebSocket upgrade responses are destroyed instead of delivered to the client in dev #15170 for the non-throwing non-101 case; a throwing Worker never even reaches the !response.webSocket branch, because dispatchFetch throws first.

Two complementary fixes, neither of which is "absorb gzip in the app":

1. Do not forward Accept-Encoding (and other content-coding headers) on the synthetic upgrade dispatchFetch. A 101 has no body; a 500 error page should not be gzipped into response.json().
2. Keep the [vite-plugin] Fix flaky WebSocket upgrade test and harden upgrade handler #14862 catch, but log / reviveError the rejection, and write a non-101 response when there is one ([vite-plugin] Non-101 WebSocket upgrade responses are destroyed instead of delivered to the client in dev #15170).

The parse itself belongs in miniflare (sibling issue). vinext currently absorbs the gzip SyntaxError so vinext dev does not exit: cloudflare/vinext#2922

Please provide any relevant error logs

SyntaxError: Unexpected token '\u001f', "\u001f�\b..." is not valid JSON
    at JSON.parse (<anonymous>)
    at parseJSONFromBytes (undici)
    at Miniflare.dispatchFetch (miniflare)
    at Server.<anonymous> (@cloudflare/vite-plugin handleWebSocket upgrade)

Node then exits with code 7 on 1.43.0 because vinext's socket-error backstop rethrows anything that is not a peer-disconnect / benign asset import.

[quantizor]

Sibling: miniflare parses that gzipped ERROR_STACK body in #15198.

Related: #15170 (non-101 upgrade responses are destroyed even when dispatchFetch returns a Response) and #14862 (catch on current main, not in 1.43.0).

[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: #15199

Summary

@cloudflare/vite-plugin's WebSocket upgrade handler forwards Accept-Encoding: gzip to miniflare.dispatchFetch; when the Worker throws on the upgrade, workerd returns a gzipped 500 JSON error that dispatchFetch tries to response.json() without decompressing, causing a SyntaxError (and process exit 7 on 1.43.0).

Classification

• Type: Bug
• Component: packages/vite-plugin-cloudflare (with related behavior in packages/miniflare)
• Severity: High
• Has Reproduction: Yes (with link) — Dev server exits on gzipped Worker 500 during WebSocket upgrade (socket-error-backstop rethrows undici JSON parse) vinext#2921
• Quality: Complete

Findings

• Created: 2026-08-15T03:24:37Z
• Author: quantizor (Evan Jacobs)
• Version: @cloudflare/vite-plugin 1.43.0, wrangler 4.107.0, miniflare 4.20260701.0, Node v24.11.0, undici 7.28.0, macOS (darwin 25.6.0) arm64
• Labels: none
• Comments: 4

Analysis

• Component identification: The report pinpoints packages/vite-plugin-cloudflare/src/websockets.ts (handleWebSocket / createHeaders) as the origin, with a secondary failure in miniflare's DispatchFetchDispatcher (dispatchFetch calling response.json() without inflating the gzipped body). This is a workers-sdk tooling bug, not a runtime (workerd) or third-party framework issue.
• Root cause is well-diagnosed: createHeaders(request) copies every request header including Accept-Encoding: gzip onto the synthetic upgrade dispatchFetch. A thrown Worker upgrade produces a gzipped 500 JSON error page that dispatchFetch then fails to parse.
• Reproducibility: A minimal reproduction is linked, and the report describes exact behavior on two code paths (v1.43.0 async upgrade listener → unhandled rejection → Node exit 7; current main where PR [vite-plugin] Fix flaky WebSocket upgrade test and harden upgrade handler #14862's try/catch prevents the crash but swallows the error and returns no HTTP response to the client).
• A fix PR already exists: In a later comment the reporter linked PR [vite-plugin] Drop Accept-Encoding on Worker WebSocket upgrades #15201 as the fix for this issue, plus companion miniflare parse fix PR [miniflare] Revive gzipped ERROR_STACK bodies in dispatchFetch #15200. Related prior work: PR [vite-plugin] Fix flaky WebSocket upgrade test and harden upgrade handler #14862 (added the try/catch + socket.destroy()) and issue [vite-plugin] Non-101 WebSocket upgrade responses are destroyed instead of delivered to the client in dev #15170 (client gets no HTTP response for the non-throwing non-101 case). Sibling issue [miniflare] dispatchFetch JSON-parses gzip-encoded ERROR_STACK 500 bodies #15198 covers miniflare parsing the gzipped error-stack body.
• Severity reasoning: On the released version (1.43.0) this crashes the dev process (exit 7); on main it silently swallows the Worker's exception and leaves the client with no response — both are seriously disruptive to local dev with WebSocket Workers.

Recommendation

Status: KEEP OPEN

Reasoning: This is a high-quality, actionable bug report against a current version, with a reproduction, precise root-cause analysis, and concrete proposed fixes. A fix (PR #15201, with companion #15200) is already open but not yet merged/released, so the issue should stay open as a tracking item until the PR lands, then be closed.

Action: Route to the @cloudflare/vite-plugin / miniflare maintainers to review PR #15201 (and companion #15200). Confirm the diagnosis against the linked reproduction, verify the fix strips content-coding headers from the synthetic WebSocket upgrade dispatchFetch and surfaces/logs the Worker exception (coordinating with #15170). Close this issue once #15201 merges and ships.

Suggested Labels: (none — the report references packages/vite-plugin-cloudflare and packages/miniflare, but no repo label was confirmed to exist from the issue data, so none are asserted to avoid guessing.)

Suggested Comment

Thanks for the detailed write-up and reproduction — this is really helpful, and thanks for opening PR #15201 (and the companion miniflare fix #15200). The analysis makes sense: forwarding Accept-Encoding: gzip onto the synthetic upgrade dispatchFetch means a thrown Worker upgrade comes back as a gzipped 500 JSON error page, which dispatchFetch then can't parse. We'll review the PRs — the two directions (not forwarding content-coding headers on the WebSocket upgrade path in websockets.ts, and surfacing/logging the Worker exception plus returning an HTTP response, tying in with #15170) look right. We'll keep this open to track the fix and close it once #15201 ships.

Structured summary (JSON)

{
  "issueNumber": 15199,
  "title": "[vite-plugin] WebSocket upgrade forwards Accept-Encoding gzip; Worker throw becomes undici JSON.parse crash",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/15199",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "High-quality, reproducible bug in @cloudflare/vite-plugin's WebSocket upgrade path (Accept-Encoding forwarded to dispatchFetch, gzipped 500 error fails response.json()) with clear root cause. A fix PR (#15201, companion miniflare fix #15200) is already open but not yet merged/released.",
  "suggestedAction": "Review PR #15201 and companion #15200 against the linked reproduction; verify the fix strips content-coding headers from the synthetic WebSocket upgrade dispatchFetch and surfaces/logs the Worker exception (coordinating with #15170). Close once #15201 ships.",
  "hasSuggestedComment": true,
  "suggestedLabels": []
}

[workers-devprod]

• Reproduction: ⚠️ Blocked. Sandbox runtime became permanently unresponsive after a heap-limit OOM during pnpm build. Every subsequent tool call (bash, read, write) fails with "Sandbox operation was interrupted while the platform was updating the sandbox runtime". Could not complete repository build or run any reproduction.

[quantizor]

Fix: #15201 (companion miniflare parse fix: #15200).