Setting Http headers like Cache-Tags inside App Routes

[LegendAlec-M]

Summary

Hi,

We are using App routes in our Next.js project v14. Our page.tsx file, calls an API endpoint with the page slug and user location as parameters to retrieve the page content. Our use case is to pick the property article_id from the API Endpoint response and set it in the HTTP Cache-Tag header
e.g. Cache-Tag: article_10.

At the moment its not possible to set Http headers inside the page.tsx file due to limitation of next.js. We have thought about adding the API call as a middleware, however it's not in the page context in middleware or we would have to duplicate calls to the Api endpoint once in middleware and once in page.tsx.

Is there a workaround that we could use at to set http headers inside the App routes (page.tsx)

Thanks in advance for you help.

Alec

Additional information

No response

Example

No response

[icyJoseph]

You must be using App Router though, no?

This is not a limitation of Next.js, necessarily, but streaming, headers are already sent. In Pages Router, you can do this in getServerSideProps though. But you keep saying page.tsx and stuff.

What is the usage at the of the day, caching in a CDN? Feels like yeah, you'd need to have a fast path in the proxy/middleware to get the data you need, preferably with a key-value store in front, to lower latency.

[LegendAlec-M]

@icyJoseph Sorry, just double checked its App Router, its to set the Cache-Tags for CDN. So the only away around this is to store the api response in middleware on a cache key and then read it in page.tsx ?

[kuldeeprajput-dev]

@LegendAlec-M Bro, I think the collaborator @icyJoseph is right here.

In App Router, page.tsx is part of the rendering/streaming flow, so it is too late to set response headers like Cache-Tag from there. The header needs to be known before the response starts.

For CDN cache tags, the better workaround is to resolve only the minimum data in middleware/proxy, like:

slug + location -> article_id

Then set the Cache-Tag header there. I would avoid storing the full API response in middleware; a small KV/cache lookup for the article_id should be cleaner and faster.

[LegendAlec-M]

Thanks @kuldeeprajput-dev , I'll give it a try.

[apoorva-01]

Your instinct is right that you can't set the header from page.tsx, but the reason matters: by the time a Server Component renders, Next may already be streaming the response, so the headers are gone. It's not an arbitrary limitation, it's a consequence of streaming.

How you solve it depends on what the Cache-Tag is actually for.

If you want Next's own cache to be tag-invalidatable, skip the header entirely. Tag the fetch and let Next track it:

const res = await fetch(`https://api.example.com/page/${slug}`, {
  next: { tags: [`article_${articleId}`] },
})

Then invalidate with revalidateTag('article_10') from a Server Action or route handler whenever that article changes. No header wrangling, and it works with the Full Route Cache.

If you specifically need the Cache-Tag response header for an external CDN (Fastly surrogate keys, Cloudflare cache tags, etc.), that's where middleware comes back in, and you can kill the double-fetch you were worried about. Have middleware do the API call, then rewrite to the page while passing the result down as a request header:

// middleware.ts
const data = await fetch(apiUrl).then(r => r.json())
const res = NextResponse.rewrite(req.nextUrl, {
  request: { headers: new Headers({ 'x-article-id': String(data.article_id) }) },
})
res.headers.set('Cache-Tag', `article_${data.article_id}`)
return res

Now page.tsx reads the id off headers() instead of fetching again, and the CDN gets its tag. One API call, header set where it's actually allowed.

One thing that won't work: headers() in next.config.js. That's static only, so it can't do per-article values.

If it's the second case, the middleware-passes-data-down pattern is the standard way people handle surrogate keys on Next today.

[Parigarg2006]

Hi Alec,

Since Next.js Server Components (page.tsx) execute during the rendering phase after the initial HTTP response stream headers have already been sent, you cannot directly modify response headers from inside the page component.

The absolute best and cleanest workaround to handle this—without duplicating your API fetch calls in a middleware—is to use a Route Handler (API Route) as a data proxy.

Solution: Route Handler Proxy

Move your external API call into a custom Route Handler (e.g., app/api/content/route.ts). Your page can then hit this endpoint, fetch the data, cleanly attach the dynamic Cache-Tag header, and pass it upstream to your CDN.

// app/api/content/route.ts
import { NextResponse } from 'next/server';

export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const slug = searchParams.get('slug');
  const location = searchParams.get('location');

  // 1. Fetch data from your external API backend
  const res = await fetch(`[https://api.yourbackend.com/content?slug=$](https://api.yourbackend.com/content?slug=$){slug}&location=${location}`);
  const data = await res.json();

  // 2. Create the response object
  const response = NextResponse.json(data);
  
  // 3. Cleanly inject your dynamic article ID into the HTTP Cache-Tag header
  if (data?.article_id) {
    response.headers.set('Cache-Tag', `article_${data.article_id}`);
  }

  return response;
}


// app/[slug]/page.tsx
export default async function Page({ params, searchParams }) {
  const slug = params.slug;
  const location = searchParams.location;

  // Fetching from your Route Handler proxy maintains a single network request to your backend
  const res = await fetch(`[https://yourdomain.com/api/content?slug=$](https://yourdomain.com/api/content?slug=$){slug}&location=${location}`);
  const data = await res.json();

  return (
    <div>
      {/* Render your page content here */}
    </div>
  );
}

[satiricalguru]

Because React Server Components in Next.js stream HTML to the client as chunks resolve, HTTP response headers must be sent before body streaming begins. That is why Next.js does not allow mutating outgoing response headers directly from within page.tsx.

Depending on whether your Cache-Tag is meant for Next.js internal cache revalidation or an external CDN (Cloudflare/Fastly/Akamai), here are the standard workarounds:

---

1. If you are trying to tag the cache for Next.js Revalidation (revalidateTag)

If your goal is to invalidate this page or fetch when the article updates on the server, you do not need an HTTP response header. You can attach tags directly to the data fetch inside page.tsx:

// app/[slug]/page.tsx
export default async function ArticlePage({ params }: { params: { slug: string } }) {
  const res = await fetch(`https://api.example.com/articles/${params.slug}`, {
    // Next.js data cache tag
    next: { tags: [`article-${params.slug}`, 'articles'] },
  });
  const article = await res.json();

  return <main><h1>{article.title}</h1></main>;
}

Whenever article content changes in your CMS/backend, trigger a webhook that calls revalidateTag('article-' + slug) to purge the cached data in Next.js.

---

2. If you need Cache-Tag on the HTTP response for an external Edge CDN

If an external edge CDN (like Cloudflare or Fastly) needs the Cache-Tag header on the full page HTML response:

Approach A: Deterministic Tagging in middleware.ts (Recommended)

If your CDN tag can be derived from the route parameter (slug), attach it in middleware.ts without duplicating the API call:

// middleware.ts
import { NextResponse, type NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const response = NextResponse.next();
  const pathname = request.nextUrl.pathname; // e.g. /articles/my-slug
  
  if (pathname.startsWith('/articles/')) {
    const slug = pathname.split('/')[2];
    if (slug) {
      // Set CDN Cache-Tag header derived from URL
      response.headers.set('Cache-Tag', `article-${slug},articles-all`);
      response.headers.set('Cache-Control', 'public, s-maxage=3600, stale-while-revalidate=86400');
    }
  }

  return response;
}

export const config = {
  matcher: ['/articles/:path*'],
};

Approach B: Serve / Proxy via a Route Handler

If the Cache-Tag must depend on an internal ID returned by the API (e.g. article_id: 10) that cannot be known ahead of time, use a Route Handler (app/api/article/[slug]/route.ts) to return the data or render the response:

// app/api/article/[slug]/route.ts
import { NextResponse } from 'next/server';

export async function GET(req: Request, { params }: { params: { slug: string } }) {
  const data = await fetchArticleFromBackend(params.slug);

  return NextResponse.json(data, {
    headers: {
      'Cache-Tag': `article_${data.article_id}`,
      'Cache-Control': 'public, s-maxage=3600, stale-while-revalidate=86400',
    },
  });
}

[usualdesigner]

You can't set response headers from a page component, that part's correct — Next doesn't expose that. But honestly I'd stop fighting the raw header and use Next's own tag system instead: tag the fetch itself with next: { tags: [article_${id}] }, then when the article changes on your end, call revalidateTag() from wherever that update happens (webhook, admin action, whatever). That gets you the same effect as a Cache-Tag purge without needing the header at all. If you genuinely need the literal header for an external CDN/purge system, that has to happen in a Route Handler, not a page render — middleware can set headers but doesn't have page context, so you'd eat the double API call like you already figured.

[satiricalguru]

Thanks for bringing this up in Setting Http headers like Cache-Tags inside App Routes. I am following this discussion and looking into the details. Happy to help test or contribute to this area!