PR #85643: Fix/prefetch always 200

• Repository: vercel/next.js
• Author: denesbeck
• State: closed | merged: False
• Link: https://github.com/vercel/next.js/pull/85643

Description (problem / solution / changelog)

Fixes: https://github.com/vercel/next.js/issues/85121

Starting from Next.js v15.4.1 (commit 256cd5b571), prefetch requests for SSG/ISR pages always returned 200 OK status codes instead of 304 Not Modified, even when the content hadn't changed. This forced full payload downloads on every prefetch (e.g., on hover or in-viewport), unnecessarily increasing CDN traffic and bandwidth costs.

Root Cause: In commit 256cd5b571 ("Add response handling inside handlers"), the Pages Router handler was modified to create RenderResult instances with Buffer.from() for cached content:

The problem: RenderResult.isDynamic returns true when the response is a Buffer (not a string):

public get isDynamic(): boolean {
  return typeof this.response !== 'string'  // Buffer !== 'string' → true
}

Test repository for testing changes (to prevent version conflicts): https://github.com/denesbeck/next-test-304 Simply package the Next.js version from this branch into the repository. Then, run npm run build and npm run start.

Note: Firefox may show different behavior as it handles prefetch caching with different strategies that don't always use the same HTTP cache validation mechanisms as Chrome. However, the server-side fix is correct and working as expected - the server properly generates ETags and returns 304 responses when appropriate. The difference is in how browsers choose to send (or not send) the If-None-Match header for prefetch requests.

Changed files

• packages/next/src/server/route-modules/pages/pages-handler.ts (modified, +11/-17)
• test/production/prefetch-304-response/app/pages/index.js (added, +12/-0)
• test/production/prefetch-304-response/app/pages/ssg.js (added, +16/-0)
• test/production/prefetch-304-response/index.test.ts (added, +73/-0)

PR #90304: Fix(pages-router): restore Content-Length and ETag for /_next/data/ JSON responses

• Repository: vercel/next.js
• Author: lllomh
• State: closed | merged: True
• Link: https://github.com/vercel/next.js/pull/90304

Description (problem / solution / changelog)

What

Removes the Buffer.from() wrapper when constructing RenderResult for /_next/data/ JSON responses in the Pages Router handler.

Why

PR #80189 introduced Buffer.from(JSON.stringify(result.value.pageData)) when building the data response. Since RenderResult.isDynamic checks typeof this.response !== 'string', passing a Buffer (not a string) caused it to return true, making sendRenderResult treat the response as a dynamic stream — skipping Content-Length and ETag generation and falling back to Transfer-Encoding: chunked.

This is a regression from v15.4.0 and breaks CDN-side compression for self-hosted deployments (e.g. CloudFront requires Content-Length to compress origin responses on-the-fly).

Fix

- Buffer.from(JSON.stringify(result.value.pageData)),
+ JSON.stringify(result.value.pageData),

Testing

• Reproduction steps verified against the reporter's repro repo: https://github.com/bbrouse/nextjs-content-length-repro
• diffcurl -sD - on /_next/data/<BUILD_ID>/index.json now returns Content-Length and ETag headers.

Affected Area

• Pages Router — /_next/data/ responses only
• No impact on App Router
• Single-line change, minimal blast radius

Fixes #90281

Changed files

• AGENTS.md (modified, +4/-4)
• packages/next/src/server/route-modules/pages/pages-handler.ts (modified, +11/-17)
• test/e2e/prerender.test.ts (modified, +16/-4)