In Next.js middleware you compute a value — say a request ID — that the Server Component handling the same request needs. How do you pass it down, and why doesn't setting it on request.headers work?

## Two pieces of server code, one channel It is tempting to think of middleware and the page as one continuous piece of server work sharing variables. They are not. Middleware runs first, decides what happens to the request, and hands control on. There is no shared module scope you can rely on, no request-scoped context object you can stash things in. The one channel Next gives you is the **request that gets forwarded inward**, and specifically its headers. ## The mechanism ```ts import { NextResponse } from 'next/server' import type { NextRequest } from 'next/server' export function middleware(request: NextRequest) { const requestHeaders = new Headers(request.headers) requestHeaders.set('x-request-id', crypto.randomUUID()) return NextResponse.next({ request: { headers: requestHeaders }, }) } ``` Three things are load-bearing: 1. **`new Headers(request.headers)`** — you copy, because the incoming headers are what arrived, not the outgoing set. 2. **the `request` option on `next()`** — this is the whole API. Without it, `next()` forwards the request unchanged. 3. **a header, not an object** — headers carry strings. Anything structured has to be serialised, and it has to be small; every proxy in the path has header size limits, and the value travels on the request whether the route uses it or not. `NextResponse.rewrite(destination, { request: { headers: requestHeaders } })` accepts the same option, so you can rewrite and forward headers in one return. ## Reading it downstream In a Server Component or a layout, use the `headers()` helper: ```ts import { headers } from 'next/headers' export default async function Page() { const requestId = (await headers()).get('x-request-id') return <p>{requestId}</p> } ``` Since Next 15, `headers()`, `cookies()` and `draftMode()` are async and must be awaited — code written against Next 14 calls them synchronously and will need updating. In a Route Handler you already have a request object, so `request.headers.get('x-request-id')` is enough. Note what reading `headers()` implies: it is a request-time API, so the segment that calls it cannot be rendered ahead of time. Passing data down this way is not free — you are also declaring that this part of the tree depends on the incoming request. ## Why mutating `request.headers` does nothing The `NextRequest` you receive models the request as it arrived. Nothing about Next's forwarding reads back from that object after your function returns; the forwarded set is exactly what you supplied through the `request` option, and if you supplied nothing, it is the original. So `request.headers.set('x-request-id', id)` either throws (a `Headers` object can be immutable) or silently changes an object nobody reads afterwards. Either way, the route sees nothing, which is a frustrating bug precisely because it looks like it should work. ## The direction mistake The other half of the confusion is the response: ```ts const response = NextResponse.next() response.headers.set('x-request-id', id) // → goes to the BROWSER ``` That sets a header on the response Next sends back to the client. It is the right tool for `Content-Security-Policy`, a debug marker, or anything the client or a CDN should see — and it is useless for talking to your own route, which has already finished by the time that header exists. Request headers travel inward; response headers travel outward. Keep the two straight and most middleware confusion evaporates. ## What does not survive A redirect ends the request. `NextResponse.redirect()` has no request-forwarding option, because there is no inward leg left — the browser starts a fresh request, and anything you wanted to carry has to be in the URL or in a cookie you set on the redirect response. ## Practical cautions Anything you forward is attacker-controllable unless you overwrite it. A client can send `x-request-id` — or `x-user-id` — on its own request, and if your middleware only sets the header conditionally, the route cannot tell your value from theirs. Always `set` (which replaces) rather than `append`, and treat forwarded headers as trusted only because middleware unconditionally overwrites them. That discipline matters most for anything identity-shaped, where a forwarded header that the route trusts becomes a bypass if middleware ever fails to run for that path.