Allow Client Components access to request headers during SSR

[juliusmarminge]

Goals

1. Allow client components to make authenticated fetch requests during the SSR prepass

Non-Goals

1. Server Components, as that's already possible using the headers() function
2. Fetch requests made from the browser will already have the required headers necessary, so the solution only needs to work during the SSR prepass phase

Background

Using the pages router you could get access to the incoming request headers in getInitialProps (NextPageContext), allowing you to fetch data and forward the headers properly.

Proposal

Could we get some primitive for this, maybe a useSSRContext that's only filled during the SSR prepass?

Note

This is already possible today, by calling headers() and passing it as props to the client component, although this means the headers are included in the HTML markup which isn't ideal as it exposes http only cookies to be read by JavaScript.

[tom-sherman]

Why do you need to fetch this data in the SSR stage? Could you not fetch this data in a parent server component and pass it down?

A specific use case example would help this discussion I think.

[juliusmarminge]

I could - but with React Query's automatic streaming provider the DX is so much better just doing it in the client component directly.

There are multiple ways of doing this, but for certain stuff it's just as good to do the fetch in the client component with better dx of not having to fetch in multiple places and passing props around...

[arackaf]

There are any number of reasons why react-query might be preferred for SSR data loading over awaiting in an RSC. This failing to be possible is incredibly frustrating

[igor9silva]

That'd be the ultimate DX.

[michaelschufi]

This would be awesome, yes!

To add another papercut...
In Next.js 15 this seems to also result in an additional error, which cannot be ignored as easily, polluting the terminal / logs.

Failed to set fetch cache http://localhost:3000/api/trpc/foo?batch=1&input=%7B%220%22%3A%7B%22json%22%3Anull%2C%22meta%22%3A%7B%22values%22%3A%5B%22undefined%22%5D%7D%7D%7D Error [AbortError]: This operation was aborted
    at signal.addEventListener.once (/path/to/app/app/.next/server/chunks/ssr/45268_@trpc_client_dist_74559c._.js:524:54)
    at maybeAbort (/path/to/app/app/.next/server/chunks/ssr/3052f_@trpc_server_dist_5a57ce._.js:1672:35)
    at <unknown> (/path/to/app/app/.next/server/chunks/ssr/3052f_@trpc_server_dist_5a57ce._.js:1714:29) {
  code: 20,

[karlhorky]

@shuding's tweet may be interesting here:

In the latest swr@beta, you can seamlessly move data fetching between client-side and server-side, or both, in an RSC framework like Next.js:

https://x.com/shuding_/status/1794461568505352693

[TkDodo]

it's a different paradigm. Here, the fetch only happens in server components, and you need to explicitly trigger it there for queries to pick that up in client components. That's a good pattern and something we want to support, too.

However, the other approach we want to support is not write anything in server components, and leverage useSuspenseQuery in a client component to also trigger fetches during the SSR run, which would then automatically prefill the cache on the client.

That works, except that headers (and thus cookies) aren't available during SSR in client components.

I understand that just accessing cookies in client components would leak them to the client, which is non wanted. Instead, an isomorphic way to read headers that would:

• always work in server components
• work in client components during SSR run
• be a noop when executed in the browser

would be nice, and has been suggested by @cramforce on twitter, too:

https://x.com/cramforce/status/1794440746210410885

[kcrwfrd]

@TkDodo the code here works in server components, client components on SSR, and is a noop in browser: #60640 (comment)

But it's problematic

• Undocumented, could be removed or changed without warning
• Won't work in non-dynamic route segment trees. Maybe it could even return a wrong value, since it's making a reference to global namespace. I'm not sure.
• Possibly other problems I'm not aware of yet

It sure would be nice to have as a proper feature, though.

[AshConnolly]

Are there no more developments with this?

[shinyruo-nmsl]

i use AsyncLocalStorage in middleware to store headers, then use it in client component, it seems ok.

[tom-sherman]

Can you share an example? I haven't been able to get custom AsyncLocalStorage stores to work inside React components.

[igor9silva]

that's interesting

[shinyruo-nmsl]

Can you share an example? I haven't been able to get custom AsyncLocalStorage stores to work inside React components.

i use it in a big project with custom server, so i can only show you brief steps about it, maybe i will use this solution in my project in the future. example:

const ASL_STORE_SERVER_KEY = 'asyncstorage-server@context';
globalThis[ASL_STORE_SERVER_KEY] = new AsyncLocalStorage();

const nextApp = next({});
const server = express();

const startServer = async function (port, isProduct) {
  await nextApp.prepare();
  const routerPath = 'some path';
  server.get(routerPath, async (req, res) => {
    const envObj = {
      req
    };
    globalThis[ASL_STORE_SERVER_KEY].run(envObj, () => {
      nextApp.render(req, res, '/some page', {});
    });
  });
  server.listen(port, (err) => {
    if (err) throw err
    console.log(`> Ready on http://localhost:${port}`)
  })
}

// use this function to get req object in client component
function getReq() {
  if (typeof window !== 'undefined') {
    return null
  }
  return globalThis[ASL_STORE_SERVER_KEY].getStore()?.req || {}

}

startServer(3000, true);

it seems that the function 'header' and 'cookie' in nextjs also use AsyncLocalStorage, but nextjs only make them valid in RSC, i use the solution above to use req in client component. since i wrapped the render process in AsyncLocalStorage, so i'm not sure it can work without custom sever?

[RIP21]

Is there any way to read request in server components? I don't seem to see an option even for server components, not to mention client components.

[kcrwfrd]

Nope, that's only available in middleware. In an RSC the best we have is headers()

[bai]

Any news on this one? Found this thread on X and wonder if this still on the roadmap.

[necmettindev]

bump

[kcrwfrd]

I came across something in a codebase that seems to work, though it is undocumented:

const useHeaders = () =>
  typeof window === "undefined"
    ? global?.__incrementalCache.requestHeaders
    : null

I have no idea how dependable this is, though. I imagine it should certainly only work when called in the subtree of a dynamic route. And since it's undocumented, it could be removed without warning.

Where I found it in use was to sniff the user agent to improve the isomorphism of a useIsMobile hook.

[phryneas]

Please don't do that.
You don't know how many requests are SSR-rendered at the same time for different users, and there will always be the risk of reading global variables populated for a different request once multiple synchronous async operations are involved.

Or in other words: this might leak sensitive secrets from one user to another.

[jwoyo]

Thanks for the heads up! @phryneas I was already thinking about checking the integrity of the header to drop it if in doubt. But that would just mean entering hell a step further. I guess, for business critical application this is still not a proper workaround.

[kcrwfrd]

@phryneas I worried that leaking state across requests was possible, thank you for making that clear.

[kcrwfrd]

I guess another answer is to use headers() in an RSC and pass it along to a context provider. But keep in mind that

• if headers() is called in a layout then it won't update between sub-routes
• This will be serialized and sent to the client

[phryneas]

You can prevent the "sending to the browser" part with https://www.npmjs.com/package/ssr-only-secrets - that way it'll be available in SSR, but not the browser.