SVGZ isn't served with the proper headers

SVGZ is a file format supported by most (all?) of the image manipulation programs that support SVG. It’s nothing more than a SVG file compressed with gzip and .svgz support is generally implemented as an alias for .svg.gz files. The recommended MIME type for .svgz file is image/svg+xml, the same as .svg files. That means that browsers cannot differentiate between SVG and SVGZ based on the Content-type header alone.

jsDelivr correctly serves .svgz files with a Content-type: image/svg+xml header. However, it incorrectly treats them exactly the same way as a .svg files; It compresses them with gzip if the client announces support for it, making them unusable. The correct way to serve .svgz files would be to never compress them and always serve them with a Content-encoding: gzip header.

I understand that jsDelivr uses a multi-CDNs structure; Is that something that can be fixed at jsDelivr’s level?

[MartinKolarik]

@JoshyPHP thanks for a very detailed description of the problem. Much appreciated!

We’ve just deployed a patch and loading SVGZ files from jsDelivr should now work correctly. You can verify it using the link you previously posted: https://cdn.jsdelivr.net/gh/s9e/s9e.github.io/emoji.svgz

That said, I need to point out that one of the advantages of SVGZ files over SVG you mentioned doesn’t really apply here:

on top of that compressing the files offline offers a better compression ratio than dynamically gzipped resources

Even if our origin servers respond with a gzipped content, the CDN providers are going to unzip it and then gzip it themselves on the fly (this is pretty much how any CDN/proxy server/… works).

[JoshyPHP]

Thanks for the awesome response time. I have to confess I have a limited knowledge of CDNs but I’ll definitely look into it to see if there’s anything I can do to avoid a bad recompression.