The Next.js Deploy Suite flagged `test/e2e/proxy-request-with-middleware`
as a Pages Router failure where API routes appeared to return 500 when a
middleware was present. The reported failure cannot be reproduced
against the prod-server: GET, POST, query strings, custom request
headers, the bare `/api` index handler, and middleware-injected request
headers all return 200 today.
The existing `pages-basic` fixture explicitly excludes `/api` from its
middleware matcher, so the existing E2E tests never drive this
combination directly. Add a focused regression test that builds a
tmpdir Pages Router fixture whose middleware DOES match `/api/*`,
boots the prod-server, and asserts the full matrix above.
The Next.js fixture's actual API handler proxies via `req.pipe(...)`,
which depends on Node `IncomingMessage` stream methods that vinext's
prod-server does not yet expose on the `req` object created by
`createPagesReqRes`. That's a separate Node-compat gap (closer to
#1338) and is out of scope for this regression coverage — leaving a
test that locks down the middleware/API handoff so the deploy suite's
underlying claim is no longer ambiguous.
James Anderson