-
Notifications
You must be signed in to change notification settings - Fork 126
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
Post Deployment MIME Type Mismatch With Safari #471
Comments
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: jetbridge/cdk-nextjs#219 |
We can probably close this one. If this is really a big issue for you then you'll need to upgrade to v3 (not supported in cdk-nextjs yet as far as i know) and use a custom wrapper or converter to change the cache-control to what you want ( You could even apply this only for safari user-agent ) |
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.
The text was updated successfully, but these errors were encountered: