> > At one point (the point at which they were removed from this file), > > including them would break Apache. > > That's probably an apache bug, but I think you're confusing the issue. > MIME standards apply to e-mail, not HTTP, and as such Apache is > irrelevant to this discussion. >
HTTP uses the same content-type values as MIME. > But I don't see why adding these MIME types -- which many other OSes > do include in their system-wide mime.types file, including many other > Linux distros -- should break Apache. Because if .gz was present, it would send the file as the associated type. If it wasn't, then it would look beyond and send the correct type with a content-encoding of "gzip". > > > A file that has been gzipped contains data, and is a particular > > > type of file: a compressed archive. > > > > Gzip, unlike tar or zip, is not an archive. It is one file. > > The fact that it contains only one file in no way makes it not an > archive. The primary purpose of data compression historically was to > make it smaller for storage: i.e. archival. Besides which, a gzipped > file need not contain only one file; see below. > You can't say "archive for transmission" and then define an archive as something "for storage". > > It has the same features as something that is "uuencoded". > > False. Something uuencoded has been re-encoded in a different format > expressly for the purpose of *transfering* it via mechanisms which > require 7-bit ASCII (SMTP). The purpose does not matter. It's an encoding. Whether it's an encoding for a 7-bit, non-clean channel or any other kind of encoding, it's still an encoding. > > In addition, gzip does not change the extension but merely adds a .gz > > extension. > > You're making assumptions that are false. That's the default behavior > of the gzip program when run against a single file (which even in that > mode can be overridden). This is not the only mode in which gzip > works. One can run it like so, for instance: > > tar xvf - . | gzip -c > my_archive.gz > That's still one file, a tar file. The fact that tar contains other files within it is not relevant. As far as gzip is concerned, it is a single entity. What type of data is that? The content type is "x-tar" (or whatever) and the encoding is "gzip". > You need not use tar... any arbitrary > program can feed data to gzip in this manner, and there need not be a > specific file type associated with it. I believe I said just that. It's arbitrary data. The type is in the original data. Gzip does not change the type, it merely encodes it in a convenient manner. > Thus again, you do not > have any way to determine what type of data is in the gzip archive. > No arbitrary stream of data has a type associated with it -- introspection of the data notwithstanding. > All that MIME knows is that this file is a gzipped archive -- except > in Debian it doesn't, because you've removed the MIME types from the > system mime.types file. So it knows absolutely nothing. > Even if it knew it was gzipped data, it would still know nothing. Knowing how it was encoded tells you nothing about what the dencoded data means. > > > Thus, both the type and the encoding are available in the filename. > > Clearly false from the above. > Clearly true if you start with a file and don't specifically choose to obfuscate the data. In the end, the amount of information about the type of data is the same both before and after gzip touches it. If it came from a file, the type (extension) is preserved. If it came as an arbitrary octet stream, the output is an arbitrary octet stream. > > There is a way to know; use content-type and content-encoding, just as > HTTP > > does. > > Please show me where in the MIME standards this is allowed. > Content-encoding is not a valid MIME header, as far as I'm aware. > Content-transfer-encoding is, but gzip is not a valid content transfer > encoding defined by the MIME standards, and in fact it can not be one, > because attachments "encoded" in gzip can not be sent as-is over SMTP. > MIME allows for extensions. I didn't say it was part of the RFC. > > > it is only suitable for MIME handlers to treat such files as > > > application data, which can be processed by the gzip program, as > > > MIME was always intended to be used. > > > > Processing by the gzip program is equally useless on its own. You're > just > > changing one stream of bytes for another. > > This is essentially true, but providing a proper MIME type prevents > e-mail clients from mishandling gzip files, for example by attaching > them with an incorrect MIME type (or none at all) or attempting to > display them as plain text when their mime-type lookup fails. > That is unfortunate, I agree. I could assign "octet-stream" as the type to the .gz file and make that go away. In the end, it's just as meaningful. > > on the file will not display the file because gzip will not display > > anything. > > > Despite the problems, mapping ".gz" to a gzip type gains nothing. > Clicking > It gains something very important: it prevents e-mail clients from > mishandling gzipped files. > But adds nothing regarding proper handling of the data. > > However, other programs (like Apache) may be smart enough to > > properly deal with the encoding and pass this information to the > > clients and creating the entry for which you ask could break a great > > many web-servers around the world. > > Again, Apache is irrelevant, because MIME standards do not apply to > HTTP. For purposes of MIME, gzip is NOT an encoding. MIME is not > HTTP, and HTTP is not MIME. > MIME may not, but Apache uses (or used) the /etc/mime.types file. Adding these definitions could break a great many webservers around the world. Brian bcwh...@pobox.com ----------------------------------------------------------------------------------------- Treat someone as they are and they will remain that way. Treat someone as they can be and they will become that way.
