- From: Dirk Schulze via GitHub <sysbot+gh@w3.org>
- Date: Wed, 19 Jun 2019 05:09:07 +0000
- To: public-svg-issues@w3.org
dirkschulze has just labeled an issue for https://github.com/w3c/svgwg as "Proposal": == A separate MIME type for svgz files is needed == Presently, both `.svg` and `.svgz` files share a mime type `image/svg+xml`. This is a problem because it means that no transport protocol/layer/application can correctly serve its equivalent of HTTP's `Content-Encoding` based off of the MIME type alone. For example, nginx (and Apache?) specify the type of files to be dynamically compressed for serving (the client's `Accept-Encoding` permitting) based off the MIME type, typically mapped from file extension in a separate (systemwide or application-specific) configuration file (in nginx's case, `mime.types`). If `mime.types` maps `svgz` to `image/svg+xml` (and it does by default), it will be compressed the same way `.svg` files (obviously mapped to `image/svg+xml`) are. Any sysadmin worth her salt will be applying *at least* gzip encoding transforms to `image/svg+xml`, as the savings are enormous (as we all know, text -- and especially verbose formats like XML -- compresses very nicely). But that means that any statically extant `.svgz` files will be double-encoded, then decoded (read: decompressed) only once by the client, before attempting to render them (incorrectly) as `image/svg+xml` not in need of any additional transforms. I propose a separate `image/svgz+xml` or similar (`image/svg+xml+gzip`?) that will allow transport applications/layers to distinguish between `svg` and `svgz` files via their MIME type alone, so that sysadmins do not need to choose between being able to serve `svgz` files and serving uncompressed plain `svg` files. (There is plenty of precedent here; e.g. `.docx` and `.xlsx` files are actually zip files but have their own MIME type to prevent exactly this sort of confusion.) --- More practically speaking, a browser served a `svgz` file as generated by the myriad of SVG editors/compressors/optimizers/etc without a gzip `Content-Encoding` will not be able to render the image due to broken encoding (tested in Firefox, Internet Explorer, and Chrome); i.e. there is no client-side heuristic already in place to address this. See https://github.com/w3c/svgwg/issues/701
Received on Wednesday, 19 June 2019 05:09:08 UTC