[PR #288] [MERGED] Rebuild request context after middleware modifies headers #447

New issue

Closed

opened 2026-05-06 12:39:51 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:39:51 +02:00

Owner

📋 Pull Request Information

Original PR: https://github.com/cloudflare/vinext/pull/288
Author: @southpolesteve
Created: 3/6/2026
Status: ✅ Merged
Merged: 3/6/2026
Merged by: @southpolesteve

Base: main ← Head: fix/refresh-request-context-after-middleware

📝 Commits (2)

51c5c12 Rebuild request context after middleware modifies headers
846648c Fix request context parity in dev server and deploy entry

📊 Changes

5 files changed (+52 additions, -6 deletions)

View changed files

📝 packages/vinext/src/deploy.ts (+9 -2)
📝 packages/vinext/src/index.ts (+11 -2)
📝 packages/vinext/src/server/prod-server.ts (+10 -2)
📝 tests/fixtures/pages-basic/middleware.ts (+10 -0)
📝 tests/pages-router.test.ts (+12 -0)

📄 Description

Summary

The production server built the RequestContext for has/missing condition matching before middleware ran. When middleware modified request headers (e.g. injecting cookies via x-middleware-request-cookie), config rules for redirects, rewrites, and custom headers evaluated against the original pre-middleware values instead of the updated ones.
Moved reqCtx construction to after middleware header unpacking so that config conditions see the current request state.

Changes

packages/vinext/src/server/prod-server.ts: Changed reqCtx from const to let and added a second requestContextFromRequest() call after middleware headers are unpacked into the web request.
tests/fixtures/pages-basic/middleware.ts: Added a path (/about?inject-login) that injects a logged-in=1 cookie via middleware request headers.
tests/pages-router.test.ts: New test verifying that config has/missing conditions see middleware-injected cookies.

_{🔄 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/288 **Author:** [@southpolesteve](https://github.com/southpolesteve) **Created:** 3/6/2026 **Status:** ✅ Merged **Merged:** 3/6/2026 **Merged by:** [@southpolesteve](https://github.com/southpolesteve) **Base:** `main` ← **Head:** `fix/refresh-request-context-after-middleware` --- ### 📝 Commits (2) - [`51c5c12`](https://github.com/cloudflare/vinext/commit/51c5c12535bd78ce47ecf69da20f157bc17fc9e8) Rebuild request context after middleware modifies headers - [`846648c`](https://github.com/cloudflare/vinext/commit/846648ce0afa4a58d97c6beae2911b3bdd060146) Fix request context parity in dev server and deploy entry ### 📊 Changes **5 files changed** (+52 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `packages/vinext/src/deploy.ts` (+9 -2) 📝 `packages/vinext/src/index.ts` (+11 -2) 📝 `packages/vinext/src/server/prod-server.ts` (+10 -2) 📝 `tests/fixtures/pages-basic/middleware.ts` (+10 -0) 📝 `tests/pages-router.test.ts` (+12 -0) </details> ### 📄 Description ## Summary - The production server built the `RequestContext` for `has`/`missing` condition matching **before** middleware ran. When middleware modified request headers (e.g. injecting cookies via `x-middleware-request-cookie`), config rules for redirects, rewrites, and custom headers evaluated against the original pre-middleware values instead of the updated ones. - Moved `reqCtx` construction to after middleware header unpacking so that config conditions see the current request state. ## Changes - `packages/vinext/src/server/prod-server.ts`: Changed `reqCtx` from `const` to `let` and added a second `requestContextFromRequest()` call after middleware headers are unpacked into the web request. - `tests/fixtures/pages-basic/middleware.ts`: Added a path (`/about?inject-login`) that injects a `logged-in=1` cookie via middleware request headers. - `tests/pages-router.test.ts`: New test verifying that config `has`/`missing` conditions see middleware-injected cookies. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>