Do not mark SVGZ files as compressible

[alrra]

Currently SVGZ files are marked as compressible.

mime-db/db.json

Lines 5866 to 5867 in 63731b4

	"compressible": true,
	"extensions": ["svg","svgz"]

---

This should not be the case as SVGZ files are basically SVG files compressed with gzip, so they are already compressed.

From https://www.w3.org/TR/SVG/intro.html#MIMEType:

It is recommended that gzip-compressed [RFC1952] SVG files have the extension ".svgz" (all lowercase) on all platforms.

[dougwilson]

Hm. I'm not sure what the course of action would be here. The "compression" applies to the mime type, not the extensions. This module is just a database of mime types, and only contains data for types. What do you think should be changed? Just remove "compression" flag from "image/svg+xml"?

[alrra]

Hm. I'm not sure what the course of action would be here.

Yes, I'm also not sure, reason why I've opened this discussion.

What do you think should be changed? Just remove "compression" flag from "image/svg+xml"?

Since SVGs are used quite a lot, and they compress very well, I personally don't think this project should not recommend SVGs to be compressed.

---

What do you think about changing compressible to an array of extensions?

"image/svg+xml": {
    "source": "iana",
    "compressible": ["svg"],
    "extensions": ["svg","svgz"]
}

[dougwilson]

I really don't want to do that, because this is a database of mime type information, not extension data. For each mime type entry we have keys that tell aspects of the type. I would be really careful changing the format in any way at this point, due to it's use, especially outside of npm (using the db.json file directly). Probably worth creating a new project at the point where the format of the main json needs to be changed.

Remember that this library is just for looking up mime types; it does not provide any mechanism to lookup extensions. In this way, this library only provides information once you know the mime type, so it does not say that svgz is compressible, only that image/svg+xml is compressible and that there are two known extensions that mime type can have.

The proposal won't for example solve the following data:

"my/type1": { compressible: true, extensions: ["my"] }
"my/type2": { compressible: false, extensions: ["my"] }

I think that we need to be really careful and not allow non-mime data creep into this module unless there is a clear discussion on exactly what this module will become and such.

As it is, there isn't an issue here because the data refers to tge mime type, and as you admit the type is in fact compressible 👍

[dougwilson]

If you are wondering on the label, it is in reference to the subject (which is seen in lists along side labels):

Do not mark SVGZ files as compressible

Because this module does not mark anything about extensions, only mime types. If there is something using this module to infer such a thing, unfortunately that is outside this module's control. There is an open issue about providing extension-based data which would then make it an issue if that declared svgz as compressible but that functionality does not yet exist.

[dougwilson]

And thinking it over more, I think shouldn't svgz extension not even be under that mime at all? I guess it would depend on if the specification for the image/svg+xml type has some kind of built in deflating? Just thinking if I compressed html and saved as htmz would that still be text/html ?

[Martii]

shouldn't svgz extension not even be under that mime at all?

https://www.w3.org/services/svg-server/

... states .svgz and .svg are valid for image/svg+xml. Relatively a new doc.

[Martii]

Additional followup notes after rereading the spec of gzip, similar questions around the web related to ~"is svgz compressible?", and some of my experience/understanding:

Summarizing

If a file is already compressed gzip will store it thus deactivating the compression and decompression algorithms and is a flat out "copy" (using 7z's terminology here) or "stored" as gzip typically refers to it.

So the accumulated answer in short is a .svgz may be additionally compressible.

Key points

• In regards to the compression level, if the HTTP RFC specifications ever add another (which they can at any point and have in my computing tenure... see here on MDN), say bzip or some other quantum level compression, to the mix one can dual compress and may achieve additional improved compression ratios. One is persistent storage compression (svgz) vs. dynamic transmission compression (the HTTP header with client/server).
• If the gzip container data (binary header, block descriptions, and trailer) is dynamically determined to not be compressible then the web gzip (HTTP transmission) will just store it.
• If one gets really bored and wants to store (the gzip term here again) the .svg data into a .svgz then there is no compression of the source... depending on how the server transmits the Content-Encoding it can optionally tell the client/server to compress/decompress using an alternate compression directly instead.
• Some .svg and .svgz may contain non-compressible data such as the data URI ... so eventually perhaps some scrubbers may employ image data compression by decoding, optimizing, and reencoding (my current rant at it being absent). Some image creator software horribly adds extra blocks of repetitive useless and unused information, usually at the tail end, which would merit additional compression at the encoded level of base64.

From the standards, other answers over the years on the web, and my humble opinion/experience over the minuscule time I've been programming over the decades in relation to my mentors the issue of .svgz being compressible is negligible and should probably not be abstracted further here because not all use cases apply to current usage of a possible value of false in the json.

Regarding the extension usage instead of boolean for that json property of compressible in this project is again... not all use cases may apply.