-
Notifications
You must be signed in to change notification settings - Fork 96
fix: adjust cache-control handling for next@15.0.0-canary.187 #2666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: adjust cache-control handling for next@15.0.0-canary.187 #2666
Conversation
📊 Package size report 0%↑
Unchanged files
🤖 This report was automatically generated by pkg-size-action |
2973a63 to
93dd2b6
Compare
| return header | ||
| .split(',') | ||
| .map((value) => value.trim()) | ||
| .filter(Boolean) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/vercel/next.js/pull/71159/files#diff-ae41ee59d88093c9c0551e12f654b1b99e4211b1c9fa6dc1471febb0361004e7R21 this can now produce invalid value like s-maxage=31536000, so we remove ~falsy/empty directives, so at least on our end we produce valid value.
Hopefully they fix their stuff in which this added .filter would do nothing (so it also won't hurt to have it always)
orinokai
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks fine to me - the tests could be simplified by only checking for the max-age and durable directives without having the next version check (since even if the stale-while-revalidate header was missing in the previous version it's kind of redundant anyway), but it doesn't hurt to be explicit so lgtm
…-produces-invalid-cache-control-somtimes
…-produces-invalid-cache-control-somtimes
Description
vercel/next.js#71159 (comment) this changes the way
stale-while-revalidateis generated - instead of always being whatever is set toswrDelta/expireTime- it now is this value subtracted byrevalidatetime - if bothrevalidateandexpireTimeis the same - then cache-control no longer hasstale-while-revalidateat all (this will be the case for example forgetStaticPropspages withoutrevalidatespecified)Documentation
Tests
Tests were adjusted (or skipped if they didn't make any sense anymore - like one that checks if
stale-while-revalidateis parameterized or notRelevant links (GitHub issues, etc.) or a picture of cute animal
https://linear.app/netlify/issue/FRB-1385/next1500-canary187-produces-invalid-cache-control-somtimes