Third-party cache provider

[alessiofrittoli]

Goals

1. Add documentation about parameters or Request Headers that could be used to no hit cached content in third party cache provider configuration.

Non-Goals

No response

Background

I'm serving a Next.js web app through a CDN with cache policy enabled. The CDN is completely ignoring URL search parameters so I'm unable to serve un-cached result when /**/*?_rsc={someKey} is requested during client-side navigation.

This is causing hard-reloads since requests made with the _rsc are not receiving text/x-component response type but the cached text/html rendered content instead.

I noticed that an RSC request header is being set when /**/*?_rsc={someKey} is requested during client-side navigation, so I'm not pretty sure if that request header could be actually used as cache key in the CDN cahce policy configuration in order to return a non-cached version, thus returning text/x-component as Next.js expects.

Proposal

Could be nice to have a dedicated section in the Caching Guide of the official Next.js doc website that documents about parameters or Request Headers that could be used as cache key in a third-party cache policy provider.

Related issue

• Docs: Third-party cache provider #83439

Discord forum Post

• https://nextjs-forum.com/post/1412787216991653921

[icyJoseph]

Oh this was a much needed discussion I think. There's info spread all around from people who has problems with Vary, etc...

So is the guidance that, one should bypass CDN if the Accept header is text/x-component, and if RSC is present (set to 1 I believe). Or cache including RSC, Next-Router-State-Tree, Next-Router-Prefetch, Next-Url to make it narrow ?

I'll ask some team members too, but would like to see opinions from people who have gone through this.

[Luk-z]

@icyJoseph yeah it would be very nice to have a documentation about how all headers used during client side navigation work and how to setup CDN.

I only have a concern about using Next-Router-State-Tree as cache key: this field contains information about the current URL and next URL. Assuming you have hundreds (maybe thousands) of pages that are fully accessible from each others, this mean that each page will generate thousands and thousands of cache entry.

I'm not sure if this is a good caching strategy.

An explanation about why the previous URL is necessary to render the next page would be very graceful :)

[icyJoseph]

Yeah - I was trying to put together some data from here #65335

There's some work going on as well with clientSegmentCache - also referenced in that issue above, that ought to help here.

Have you used any CDN caching strategy?

[Luk-z]

Currently we are using Next-Router-State-Tree headers as cache key, but we have too many cache entry for a single page.
We completely disable prefetch.