- From: Mahmoud Al-Qudsi via GitHub <sysbot+gh@w3.org>
- Date: Sat, 08 Jun 2019 01:29:14 +0000
- To: public-svg-issues@w3.org
mqudsi has just created a new issue for https://github.com/w3c/svgwg: == 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 is 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. Please view or discuss this issue at https://github.com/w3c/svgwg/issues/701 using your GitHub account
Received on Saturday, 8 June 2019 01:29:15 UTC