[PR #485] [MERGED] fix: middleware custom response corrupts binary bodies in dev #607

New issue

Closed

opened 2026-05-06 13:09:02 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 13:09:02 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/cloudflare/vinext/pull/485
Author: @NathanDrake2406
Created: 3/12/2026
Status: ✅ Merged
Merged: 3/12/2026
Merged by: @james-elicx

Base: main ← Head: fix/middleware-dev-response-parity

📝 Commits (1)

48832eb fix: middleware custom response corrupts binary bodies in dev

📊 Changes

3 files changed (+46 additions, -1 deletions)

View changed files

📝 packages/vinext/src/index.ts (+1 -1)
📝 tests/fixtures/pages-basic/middleware.ts (+24 -0)
📝 tests/pages-router.test.ts (+21 -0)

📄 Description

Summary

The dev server read middleware custom response bodies with response.text(), which decodes bytes as UTF-8 — this corrupts any binary response (images, protobuf, etc.)
The prod server already uses response.arrayBuffer() + Buffer.from() correctly (prod-server.ts:961)
One-line fix: swap text() → arrayBuffer() in the dev middleware response path (index.ts:2153)

Note: The original audit also flagged multi-value Set-Cookie loss via Headers.forEach() coalescing, but testing confirmed the dev path uses for...of + appendHeader() which correctly preserves separate Set-Cookie entries per the modern Fetch spec. Added a regression test for that too.

Test plan

Added middleware fixture route /binary-response returning a 1x1 PNG
Added middleware fixture route /multi-cookie-response returning 3 Set-Cookie headers
Test: middleware custom response preserves binary body — verifies PNG magic bytes survive round-trip
Test: middleware custom response preserves multiple Set-Cookie headers — regression test
Lint, format, typecheck pass locally
CI passes (format, lint, typecheck, vitest, playwright)

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/cloudflare/vinext/pull/485 **Author:** [@NathanDrake2406](https://github.com/NathanDrake2406) **Created:** 3/12/2026 **Status:** ✅ Merged **Merged:** 3/12/2026 **Merged by:** [@james-elicx](https://github.com/james-elicx) **Base:** `main` ← **Head:** `fix/middleware-dev-response-parity` --- ### 📝 Commits (1) - [`48832eb`](https://github.com/cloudflare/vinext/commit/48832ebf14c0be7b29779995429e2ed736ee3532) fix: middleware custom response corrupts binary bodies in dev ### 📊 Changes **3 files changed** (+46 additions, -1 deletions) <details> <summary>View changed files</summary> 📝 `packages/vinext/src/index.ts` (+1 -1) 📝 `tests/fixtures/pages-basic/middleware.ts` (+24 -0) 📝 `tests/pages-router.test.ts` (+21 -0) </details> ### 📄 Description ## Summary - The dev server read middleware custom response bodies with `response.text()`, which decodes bytes as UTF-8 — this corrupts any binary response (images, protobuf, etc.) - The prod server already uses `response.arrayBuffer()` + `Buffer.from()` correctly (`prod-server.ts:961`) - One-line fix: swap `text()` → `arrayBuffer()` in the dev middleware response path (`index.ts:2153`) **Note:** The original audit also flagged multi-value `Set-Cookie` loss via `Headers.forEach()` coalescing, but testing confirmed the dev path uses `for...of` + `appendHeader()` which correctly preserves separate `Set-Cookie` entries per the modern Fetch spec. Added a regression test for that too. ## Test plan - [x] Added middleware fixture route `/binary-response` returning a 1x1 PNG - [x] Added middleware fixture route `/multi-cookie-response` returning 3 Set-Cookie headers - [x] Test: `middleware custom response preserves binary body` — verifies PNG magic bytes survive round-trip - [x] Test: `middleware custom response preserves multiple Set-Cookie headers` — regression test - [x] Lint, format, typecheck pass locally - [x] CI passes (format, lint, typecheck, vitest, playwright) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>