The website encoding is broken on Safari
Hey, folks! There is seems to be an encoding issue that's only related to Safari, the "homepage" doens't load with the proper encoding, https://serce.me/. At the same time, the website loads fine from Chrome. It's a nextjs app, https://github.com/SerCeMan/SerCeMan.github.io, that's deployed to Cloudflare Pages.
SerCe's blog
SerCe's blog
SerCe's blog: Here is my personal blog where I share my thoughts and experiences with different technologies.
28 Replies
An empty redeployed fixed the issue.
No, unfortunately some pages are still broken on safari
this is due to cloudflare ignoring Accept-Encoding headers and returning zstd encoded files
you should be able to fix this by adding a Compression Rule in cloudflare console and turn off zstd
at the end of the day its a cloudflare bug I hope they recognize
Would have to see the response to be sure, but my understanding is the root of that issue is caused by enabling "Strong Etags" in a cache rule
In my case, I never enabled this.
do you have the headers of a wrong response? the only ones I've seen on the forums were from that and that's what CF Support said as well when they looked into it, would be interesting to see otherwise
you can see at the URL firecrits.com
I haven't messed around with etags too much but it does look like the images subdomain has strong etags on
well the images (from r2) are one thing, I am more concerned with the JS files compressed with zstd and becoming unparsable by safari
The js resources at least on the front page look proper with weak etags, but still if you've got it on for some of the assets then perhaps you enabled it more, would be worth a check through your rules, both Cache Rules and Page Rules have the Strong ETags Option
keep in mind also, some JS files compress correctly, some are zstd, you may need to look for them
if the page is loading white with no styles its because a JS file is broken, Safari even shows an error in the console saying a character or something cant be parsed
Thanks, I should've captured a HAR. I definitely didn't touch any config, but all of the sudden the page started breaking on Safari without any redeployments. A redeploy solved plus clearing the caches solved the issue.
Oh no! I was able to reproduce it just now, here's the HAR file in case it's useful @Chaika
But yes, that's exactly it, zstd, when gzip, br is requested
Looks like this is clearly a bug
I've been having similar issues
We've been discussing this issue here https://community.cloudflare.com/t/zstd-serving-to-safari-no-solutions-for-free-plan/820998/37 (it's been happening to me for the last 10 days...), please add your findings there! Hopefully someone from Cloudflare is reading that thread
Thanks, added my findings
The status page however says that the issue has been mitigated, https://www.cloudflarestatus.com/incidents/psbtf5g99qjc
Thanks, that is helpful, I forwarded it. We've reported this a few times but I think there's been some trouble with reproing it exactly
That looks like next on pages? Wonder if it returning a response from the Worker like that is related at all,h mm
I'm also using nextjs btw, if that helps... maybe it is related to it specifically?
Nevertheless, I've tried going between two major versions (13 and 15) and it breaks on both, so it's not one specific nextjs version
It could be related to the way it's making/returning responses, although there's def been examples without nextjs headers, you'd be using the same next-on-pages adapter regardless of the nextjs version so
Ah sorry, I didn't know that next-on-pages is a specific CLI tool (just googled it), thought you meant just "using nextjs on Cloudflare" in general
I'm using statically exported nextjs uploaded to Cloudflare Pages through Wrangler actually
yea then that's fully static and points to it just being some generic issue with the way Pages Custom Domains work (orange to orange), like was thought before. Well, hopefully they can get to the bottom of it soon
Makes sense, and yeah, hopefully...
@Chaika are you able to reproduce this issue currently?
I can't currently no, if we repro consistently this would be a lot easier
Thank you, we have escalated this to our engineering team for further investigation
It's not NextJS related. I've had the issue on two client sites using SvelteKit
@SerCe can you let us know as soon as you see it again, as I currently can't reproduce, or see a known way this should currently happen for this url/zone
ah, if you cleared caches and hadn't since the incident on the status page was resolved, you may have had a lingering cached zstd object
Yeah, if the caches weren't cleared, then this could've been the culprit. I assume there are others who've got incorrect responses stuck in caches, though.
Just wondering whether the fix means that those of us who switched Zstd off can turn it back in so that browsers that do support it can benefit again. Is this feature no longer sending Zstd to Safari users?