[svgwg] A separate MIME type for svgz files is needed (#701)

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