Why am I getting 'RSC' code instead of content after implementing custom headers in my middleware?

[Gavrushuk]

Version of Next js - 14.2.23

I have implemented custom headers, including Last-Modified, ETag, and Cache-Control in the middleware. When a page has not been updated, it successfully returns a 304 Not Modified status code.

const lastModifiedDate = new Date(lastModified).getTime();
const ifModifiedSinceDate = ifModifiedSince ? new Date(ifModifiedSince).getTime() : 0;

if (
  ifNoneMatch?.includes(etagValue) ||
  ifModifiedSinceDate >= lastModifiedDate
) {
  return new NextResponse(null, {
    status: 304,
    headers: response.headers,
  });
}

I retrieve the updated_at timestamp for each page and use it to set the Last-Modified header, generate a hash for the ETag header, and calculate the appropriate value for the Cache-Control header.

However, on certain pages, the content is being replaced with 'RSC' code instead of the expected content.

[icyJoseph]

I guess my first question is, why not use the default Next.js E-Tag behavior?

Where's response coming from here? At first I though _rsc query params not being included in middleware could be the issue, but AFAIK, the browser uses full URL to cache these things, so it'd know that it is different content. Could it be a hosting issue? I remember some providers had a very similar this issue when RSC was introduced.

[Gavrushuk]

Many pages where I need to use ETags are dynamic. I've researched this and it seems that ETags don't work for dynamic pages, only for static ones. Is this correct?

For example, I have a dynamic article page and need to return a 304 status if the article hasn't been updated.

Response variable
const response = NextResponse.next();

Regarding my code, I have a condition for RSC, but it doesn't seem to be helping:

const isRscRequest = req.headers.get("RSC") === "1";
const isPrefetch = req.headers.get("Next-Router-Prefetch") === "1";

// Skip Next.js internals, static assets, and RSC/JSON data requests
if (
  pathname.startsWith("/_next/") ||
  /\.[a-zA-Z0-9]+$/.test(pathname) ||
  searchParams.has("_rsc") ||
  isRscRequest ||
  isPrefetch
) {
  return NextResponse.next();
}

[icyJoseph]

I think the RSC header is removed before it hits middleware, same as the _rsc query param

🤔 in what flow do you see this issue? got any browser headers screenshots?

[Gavrushuk]

When I navigate to a dynamic page, either directly or from another page, I encounter this problem. However, it doesn't affect all pages, and a hard reload consistently fixes it. The behavior is also inconsistent among users; for some, the content loads correctly, while for others, it displays RSC code, and vice versa.

Headers of page that shown RSC code instead content:
Response

HTTP/1.1 304 Not Modified
Server: nginx
Date: Wed, 20 Aug 2025 08:56:49 GMT
Content-Type: text/html; charset=utf-8
Connection: keep-alive
cache-control: max-age=2592000, stale-while-revalidate=86400
etag: "c701e71e"
last-modified: Tue, 18 Feb 2025 10:34:28 GMT
Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept-Encoding
link: </_next/static/media/1f3fe8c6df3d47c1-s.p.woff2>; rel=preload; as="font"; crossorigin=""; type="font/woff2", </_next/static/media/24c66e387ee021e3-s.p.woff2>; rel=preload; as="font"; crossorigin=""; type="font/woff2", </_next/static/media/39bb59f36a089004-s.p.ttf>; rel=preload; as="font"; crossorigin=""; type="font/ttf", </_next/static/media/5f324d93087fc43c-s.p.ttf>; rel=preload; as="font"; crossorigin=""; type="font/ttf", </_next/static/media/9829769a3a6cd188-s.p.ttf>; rel=preload; as="font"; crossorigin=""; type="font/ttf"
X-Powered-By: Next.js
Content-Encoding: gzip

Request

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8,uk;q=0.7,ru;q=0.6
Connection: keep-alive
If-None-Match: "c701e71e"
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36
sec-ch-ua: "Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "macOS"

[Gavrushuk]

I tried setting the Last-Modified, ETag, and Cache-Control headers in the middleware, but the logic for returning a 304 Not Modified response was moved to NGINX, and I still have the same problem

[CoderDeltaLAN]

Context

• Version: Next.js 14.2.23
• Env: Middleware (middleware.ts)

Cause
Middleware runs before the RSC pipeline and only allows request inspection and rewriting/redirects. Returning a Response with custom headers from middleware will short-circuit the RSC processing. That’s why you see the raw RSC payload instead of rendered HTML.

Fix (minimum viable)

1. Keep middleware minimal:

   import { NextResponse } from 'next/server'
   
   export function middleware(req: NextRequest) {
     return NextResponse.next()
   }

   You can still attach headers here, but avoid handling 304 logic.

2. Move Last-Modified / ETag / Cache-Control logic to:

   • A route handler (app/api/.../route.ts) or
   • A custom server / edge function.

   Example in a route handler:

   export async function GET(req: NextRequest) {
     const res = NextResponse.json(data)
     res.headers.set('Last-Modified', new Date().toUTCString())
     res.headers.set('Cache-Control', 'public, max-age=60')
     return res
   }

3. If you need conditional 304:

   • Check If-None-Match or If-Modified-Since inside the route handler.
   • Return new Response(null, { status: 304, headers }) there.

Notes

• Middleware can’t safely return 304 for dynamic pages, because RSC expects the full server response.
• Docs: Next.js Middleware and Route Handlers.

If this solves it, please Mark as answer so others can find it.

[CoderDeltaLAN]

Agree. This looks like a variant cache key issue. _rsc and the RSC header are stripped before middleware, so a 304 decided in middleware or at NGINX can point the browser to the wrong variant. Fix: do not issue 304/ETag for HTML in middleware or NGINX, let Next.js handle its own ETag. Limit custom 304 to static assets. If you must cache HTML at the edge, vary by RSC, Next-Router-State-Tree, Next-Router-Prefetch, and Accept. Hard reload working matches this.

[Gavrushuk]

But if I try to watch by the "Accept" field in headers and check if this field value includes "text/html", then add headers and 304 logic only for these pages?
I'm not sure, but it should prevent the RSC code response.

[Gavrushuk]

Seems like it's impossible because the RSC code response has the same headers as for the correct response

[Gavrushuk]

We can't abandon 304 for the articles page (dynamic) because it's important for SEO. But I have no idea more

[CoderDeltaLAN]

Try this, disable 304/ETag handling for HTML in your middleware or proxy and let Next.js set its own ETag (keep 304s only for static assets). If you cache HTML at the edge, add Vary: RSC, Next-Router-State-Tree, Next-Router-Prefetch, Accept so the right variant is served. Clear the proxy/CDN cache and hard-reload; if it still happens, I can share a small repro and a sanitized proxy config to debug together.