On Mon, Aug 30, 2010 at 03:16:08PM +0200, Brian White wrote: > > Everything is an encoding. HTML is an encoding. MP3 is an encoding. > > ASCII is an encoding. All digital data on a computer is an encoding > > of some sort. Purpose *absolutely* matters. > > > > All of those are more than an encoding. They apply some meaning to the > data. > > As you say, purpose matters. There is no purpose to data just because it's > gzipped.
False. The purpose is to take up less space. > > But how does mime-support identify what the file type is? It can't... > > because the file type of *this file* is gzip data, and you've not > > provided a type for that. > > > > It's smart. It recognizes the indication that the data has been > compressed and then uncompresses it before using the type of the > data to determine the proper destination. No, HTTP does this. MIME, as I have said repeatedly, has ABSOLUTELY NO PROVISION to do this. And yes, it's extensible, but *FOR MIME, NO SUCH EXTENSIONS EXIST*. And in the case of gzip data, they *CAN NOT EXIST* because gzip *CAN NOT POSSIBLY* be an encoding that can be transfered via SMTP. Attempting to treat it as an encoding would break SMTP. As such, MIME allows gzip data to be treated only one way: as application data for the program gzip. > Gzipped data is not a type. It absolutely is. Your failure to recognize this simple fact is the sole reason that your mime package is broken and that some mail programs have trouble correctly dealing with gzip files. Other systems correctly recognize it as a file type, and suffer from NONE of the problems you suggest that millions of systems might suffer from. > Yes, with a type, some mail programs may better handle the file > because it won't treat it as text but dumping the uncompressed > output isn't any better. The point is they will do no such thing. They will correctly recognize these files as compressed archives, and allow the user to do what is intended to be done with them: store them on disk compressed. That is the purpose of gzipped files. To be stored in less space than they would otherwise occupy. Providing a type allows mail clients to do exactly that. Not providing one causes them (in at least some cases) to fail. > > Then fix Apache. Or explain why other Linux distros which do have > > these types (e.g. most any Red-Hat based distro) don't have this > > problem... > > > > Apache used to come with its own mime.types file independent of the > system. The Debian package used the system one. So, in other words, Debian broke it. Debian failed to recognize that MIME and HTTP treat data types differently, and continues to do so. And instead of fixing it properly, Debian decided to break MIME to make it work for HTTP. Brilliant. > *You* fix apache! And fix all previous releases. And push that change to > every Debian-based webserver on Earth. Then we can talk. There's nothing to do, except for debian to reverse it's ill-conceived, broken policy decision. And fixing that is exactly what I'm attempting to do now. Unfortunately I lack the required access to make the necessary change. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
pgpa7piHg9cJf.pgp
Description: PGP signature
