Cloudflare Is Breaking My SVGs?
lloydatkinson.net
lloydatkinson.net
An important note: React-based frameworks tend to use camelCase attributes vs. hyphen-case (which is the output) in components: including the icon library being used here. Something during the build process is not converting them to hyphen-case.
* I've pasted a decently complex SVG exported from Figma into a Remix component verbatim (hyphen-attributes) and it renders fine: https://9b14a265.test-broken-svgs-remix.pages.dev/ (scroll down)
* I've rewritten those attributes to camelCase: and again, renders fine - https://1af766a8.test-broken-svgs-remix.pages.dev/
* This is all deployed via the Pages Build system; no local builds at all.
* Someone else on the team has an Astro example stood up with the specific unplugin-icons library: https://astro-svg.pages.dev/ - cannot reproduce the invalid SVG attributes.
We're going to continue investigating but don't see this as widespread and don't yet have any other reports. That there is a _difference_ between the direct deploy vs. using Pages Builds is a problem, though. We've also asked the Astro folks to understand if there's something up here as well.
(If not clear: I work at Cloudflare)
My guess would be that there is some specific bit of information set during the build that triggers this incorrect build in Astro, and this information is set only by the Cloudflare build process. But here the people from Cloudflare are struggling to reproduce that effect, so it looks very specific to this person's setup.
Weird behaviour. I'm interested in reading the actual reason that build ends up doing this.
(Side note: I really wish people would leave out the image memes when writing something like this. The animated one at the end even makes it hard to read the final paragraph.)
EDIT: OP please drop me an email. Three of us internally at Cloudflare have tried to reproduce this and failed and we need to chat with you about what's in your build process so we can try to narrow this down. Cheers!
I made a simple test: https://jgc.org/svg and we made a couple more using Astro: https://misty-mouse-d370.pages.dev/hello and https://cec6e042.laz-svg-test-assets.pages.dev/.
The radio silence normally causes me to assume that it wasn't our service/platform but a PEKBAC issue.
It's an example of a product that's well designed, generous in its free-tier, yet occasionally confounding, probably due to the speed their team moves.
Also wanted to add that I appreciate the author writing about the bug and their debugging process. That's definitely something I wish I had done more of, instead of thinking at the time 'I filed the issue, does the whole world need to know about this?'
(Sometimes daily reading of HN can have this effect, I think)
Then months go by, the issue I filed was moved or something happened to it, and I lost a way of tracking it... So I think it's important to a.) file the issues but b.) document the issue in your own way while everything's fresh in your mind.
I investigate a lot of esoteric bugs at work and I always push people for a https://sscce.org/.
In this case what would have helped massively:-
- A minimal astro page with the a broken svg hosted on CF pages (using npm create astro@latest -- --template minimal)
- The same hosted on Netlify
- a public github repo that contains the minimal repro.
- A link to your internal build output that the CF folks could look at internally
- Exactly how you are including the SVG in the Astro build (I played with it and it appears there are 2-3 ways)
I always try and put myself in the place of receiving a bug report and this is the kind of thing I end up including in the bug report.
It seems from the articles conclusion that it shouldn't be related. But I had similar issues with SVG and css when I first deployed my nuxt app to CF pages. I only thought to try turning off CF minification because there was some tiny footnote about it being an issue on CF somewhere in the nuxt docs or maybe GH issues.
shrug
Many of the times I’ll just refuse to use the site, but some things I need to endure.
They clearly have no incentive to be better either. The pain falls entirely on the visitor.
If you can’t tell I’m human then you’re doing it wrong.
I'm gonna go out on a limb and say that if multiple multi-billion dollar companies struggle with it, then it's less of a solved problem than you're implying.
> Especially if you run a VPN on your router.
Very few people do this, and almost all of them are also using ad blockers. If using Cloudflare protects a site from thousands of bot attacks while inconviencing a few real users with esoteric setups, that tradeoff is well worth it for most site owners.
I've set up Cloudflare on hundreds of websites and when you look at the amount of nasty stuff it blocks, it quickly becomes clear why it's needed. If you want to blame someone, blame the Russian and Chinese governments (among others) for doing little to nothing about their unfathomably massive botnets.
Also, why would it be easy to tell that your request is from one of the good guys?
So I think, it's between your framework and cloudflare pages.
I used to use cloudflare on my static website and I had no idea I was blocking all tor users until someone on HN let me know.
Cancer is too strong a word though. It’s more like a bad case of jock itch IMHO.
I agree that it's a bit opaque, but I think that comes with the territory. If Cloudflare could tell you exactly which groups were getting blocked, then DDOS protection wouldn't be so big a problem in the first place - you just select all the bad actors and block them, and you're fine.
How was that? Last time I tried to submit a bug report there the experience was terrible ...
The best way in Discord is to post in a forum channel like #pages-help or #general-help. There's tooling the community has to actively monitor and reply to those, vs a fast-moving text channel where things can be buried quickly. This is one of the reasons Discord isn't a great platform for offering support.
Community Champs / MVPs have the ability to escalate some things, but posting on HN will always get more attention. We've been raising issues around some things that are impacting lots of people every single day (wrangler.toml + Pages config breaking projects regularly for example), but if you want something fixed quickly, making some noise on social media is always going to be the quickest way, sadly.
Please let me know what you think we should improve (either here or email me vmarin@cloudflare.com)
Disclaimer: I have never used CloudFlare Pages or Netlify.
Tell me you refuse to learn awk/sed (even Windows compatible versions such as from Git Bash, WSL, or Cygwin) without telling me you refuse to learn awk/sed.
Why anyone would think a glorified regex is a solution to updating deeply nested HTML elements is beyond me, is the famous "HTML regex"[1] answer not enough? As bad a sugesting Chrome should just be a wrapper for sed/awk.
[1]: https://stackoverflow.com/questions/1732348/regex-match-open...
"Moderator's Note
This post is locked to prevent inappropriate edits to its content. The post looks exactly as it is supposed to look - there are no problems with its content. Please do not flag it for our attention."
I'll try: "You could've used awk/sed". Great comment?