Open clemsonfan101 opened 1 month ago
Just wondering, are you removing previous assets? You should probably keep at least assets from previous deployment. If you remove them, people using the website while you do a new deployment will have crash.
Yes. I'm using most of the default behavior of https://github.com/jetbridge/cdk-nextjs
At the moment, I have few enough users, that I can monitor when it's in use and deploy in the after hours.
I was thinking though that if the page itself was never cached on the client but the bundles were, then it wouldn't matter. Because if someone refreshed they'd get the new html that references the new bundles anyway.
Look what just went up 27 minutes ago: https://github.com/jetbridge/cdk-nextjs/pull/219
Context
I posted this issue to discord and I started rolling my own solution, but then I realized my solution might have unintended consequences. I'm posting here to see if there's a more accepted answer.
Problem
After a deploy to AWS using CDK, when I attempt to refresh the page with Safari, I get nothing (white screen) until I do another refresh. I debugged this down to the fact that safari (v16 in my case) is caching the html because there is an s-max-age set to indefinite but no max-age. So on the first refresh it uses the cached html which references the now invalidated js bundles. Cloudfront returns a 403 (as expected) on these bundles with an xml response body. Safari then sees this xml as a mime type mismatch and throws its hands up. The subsequent refresh then fetches all of the new html and all is well again.
My understanding was that the browsers shouldn't be using s-maxage, but rather those were meant exclusively for the private caches.
For what it is worth, I also do not have any middleware in next, and I'm not doing anything else funky that should have an effect on these headers.