stale-while-revalidate header used without delta-seconds

[NobodysNightmare]

Verify canary release

• I verified that the issue exists in the latest Next.js canary release

Provide environment information

N/A

Which area(s) of Next.js are affected? (leave empty if unsure)

No response

Link to the code that reproduces this issue or a replay of the bug

https://github.com/vercel/next.js/blob/913b365d85011473c0ec595791afa6d924a988c4/packages/next/src/server/send-payload/revalidate-headers.ts#L25C53-L25C53

To Reproduce

Render a page using getStaticProps in production. According to the docs and consistent with the source code this will serve a Cache-Control header in the form of:

Cache-Control: s-maxage=REVALIDATE_SECONDS, stale-while-revalidate

Describe the Bug

stale-while-revalidate does not specify a delta-seconds value describing for how long the shared cache (e.g. CDN) is allowed to serve stale responses while revalidating the cache.

Expected Behavior

stale-while-revalidate must specify a delta-seconds for how long a shared cache is allowed to serve stale responses while revalidating. E.g. a valid header would be:

Cache-Control: s-maxage=60, stale-while-revalidate=60

I cross-read the informal resources at MDN and AWS CloudFront docs, none of them mentioned leaving out the delta:

• MDN
• CloudFront
• An article linked from next.js docs

Thus I also checked RFC 5861, which is specifying the header. The ABNF for the header is defined as

stale-while-revalidate = "stale-while-revalidate" "=" delta-seconds

As you can see none of the parts is marked as optional, also the text does not refer to a default behaviour to assume if the value is left out. So I am pretty sure that according to the specification it is not allowed to leave out the time.

This might cause our CDN (CloudFront) to ignore the header entirely, resulting in poor page performance every 60 seconds (when periodically reloading the page).

Which browser are you using? (if relevant)

No response

How are you deploying your application? (if relevant)

AWS Amplify

[NobodysNightmare]

Tried going backwards in time a bit. So the stale-while-revalidate header was introduced 4 years ago in #8846. I could also find a reference of stale-if-error being removed (I was about to write a feature request for this header) for compatibility with the "Now CDN".

Wondering whether this CDN (I am unable to find it through a search engine) would accept stale-while-revalidate without a time specification, which would be an explanation for the current implementation.

Also CloudFront support for this feature is only a month old, so to me it is expectable that not a lot of people noticed this issue so far, if they were using AWS.

[NobodysNightmare]

Just confirmed that AWS CloudFront indeed ignores the stale-while-revalidate header served by next.js, while it accepts this header when a time is being specified.

CloudFront sends an x-cache HTTP header to tell you about how it served your request. Repeatedly calling the same endpoint on next.js (with Cache-Control: s-maxage=60, stale-while-revalidate), I get either x-cache: Hit from cloudfront or I get x-cache: Miss from cloudfront (roughly every 60 seconds). That's it.

Trying repeated calls on a custom NGINX page with s-maxage=10, stale-while-revalidate=300 gives me x-cache: Miss from cloudfront for the very first request and afterwards it's either x-cache: Hit from cloudfront or every 10 seconds x-cache: RefreshHit from cloudfront.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.