On Wed, Sep 01, 2010 at 03:11:15PM +0200, Brian White wrote: > > > 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. > > > > That's why you compressed it.
Yes, exactly; that's its purpose.
> That's not the purpose of the data.
You apparently don't speak the same English as the rest of us.
pur·pose
/ˈpɜrpəs/ Show Spelled [pur-puhs] Show IPA noun, verb, -posed,
-pos·ing.
–noun
1. the reason for which something exists or is done, made, used, etc.
So yes, absolutely and unquestionably, that is its purpose. Data is
gzipped so that it will be smaller than it originally was. By
definition, purpose. Whatever type of data it was before it was gzip
data is irrelevant, until it is uncompressed and therefore no longer
gzip data. It can not be used for whatever purpose it formerly had
until after it has been reprocessed by gzip or equivalent.
> > No, HTTP does this. MIME, as I have said repeatedly, has ABSOLUTELY
> > NO PROVISION to do this.
>
> You didn't ask about MIME. You asked about how "mime-support" does it. My
> program is smart.
False. Reread my bug report. The whole point of filing it was to fix
MIME support for gzip and compress data, which should be immediately
obvious upon even a casual reading of this bug. The bug is, of
course, quite naturally filed against the mime-support package,
because this is where debian has put the mime.types file, which is how
Unix systems look up the system-wide definitions of MIME types.
> Gzipped data is not a type. Just because other systems associate a
> type with a .gz extension does not mean that is correct. It's an
> encoding.
One more time for posterity: There is no such concept in MIME. So, at
least for the purposes of discussing MIME (which is my only purpose
here), you are simply wrong. It may well be an encoding (whatever
that even means) in countless other contexts, but for purposes of
transfering the file as an e-mail attachment, calling gzip an encoding
has no meaning and no value. You've repeatedly insisted that gzip is
an encoding, whereas other file types are types; but your distinction
is completely arbitrary and utterly invalid in the context of the MIME
standards.
Pretty much everyone else in the known universe treats gzip as a file
type. Only debian and its derivatives treat it differently, in my
experience. Don't you think that the overwhelmingly most likely
reason Debian treats it differently is because you got it wrong?
> You want to assign a type to it because you believe it will make
> things work better.
False. I want to assign a type to it because that is the correct
thing to do: Pursuant to RFCs 2045 and 2046 it SHOULD be assigned a
type of application, and is widely accepted to have any of several
well-known subtypes related to gzip. Failing that, as described by
RFC 2046 section 3.5, it should at least be associated with
application/octet-stream, to expressly allow for the user to save it
as binary data.
Now, yes... I want it to be configured correctly, because that will
in fact make things work better. Search the internet yorself for problems
related to this; there are many, many. I provide just a few, below.
> > > Yes, with a type, some mail programs may better handle the file
> > > 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 makes no sense at all. Disks don't care about the "type" of the data
> so data, compressed or not, can *always* be stored on disk. MIME has
> nothing to do with that.
Once again, you are wrong. Quoting RFC 2046, section 3.5:
(5) application -- some other kind of data, typically
either uninterpreted binary data or information to be
processed by an application. The subtype "octet-
stream" is to be used in the case of uninterpreted
binary data, in which case the simplest recommended
action is to offer to write the information into a file
for the user. [...]
The MIME standards deal directly with the very thing you say MIME has
nothing to do with. It is sad that the authors did not expressly
mention gzip, as it seems this is the only way you will be able to
grasp that this is the purpose and intent of e-mailing gzip files, and
how that should be handled under MIME, and as such mime-support is
broken in Debian.
> > 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.
> >
>
> Fail how?
Any of several ways, including trying to display the file as plain
text (with or without first decompressing it), or using some
half-baked algorithm to try to guess what type of file it is. For
example:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541241
In fact, the assertion that gzip is not a MIME type is not just a
problem for e-mail clients (all of these are web server related and
caused by Debian's lack of a gzip MIME type):
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/245219
http://youtrack.jetbrains.net/issue/IDEA-53544
http://bugs.php.net/33829
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=126041
http://www.directadmin.com/forum/showthread.php?t=36103
There are many more of these. Debian's (lack of) handling of gzip as
a MIME type is broken, even with respect to HTTP. HTTP's handling of
gzip as a content encoding is intended to be transparent to the user:
if the file is stored on the server as a .gz file, it should arrive at
the user's end as a .gz file. Apache (or whatever web server) should
not tell the client to decompress it. The content encoding is part of
the HTTP protocol, i.e. the protocol that defines communication
between the web server and client. Once communication via the HTTP
protocol has ended, the file received should be exactly the same as
the original source file. The transfer should not transform the data
that is so transfered; evidently under Debian, it is, when the source
is already a gzipped file. Broken.
> > 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.
>
> Hindsight is always perfect.
And having hindsight, you can always fix your mistakes. Even if you
don't fix it for current versions, you can correct your broken policy
and fix it for future ones.
> You can always build your own mime-support package from source and install
> that on your own workstations.
There are plenty of ways to work around the problem, none of which fix
the underlying problem, which is: Debian package maintainers are
confused about the fact that gzip is in fact a MIME type (they believe
it is not), and as a result every Debian system comes pre-broken by
the maintainers. And then it must be fixed manually by whoever wants
to (or, as in my case, must) use Debian. Which according to you, is
millions of servers. How inefficient is that?
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
pgpgpsFZyTwoW.pgp
Description: PGP signature
