Sander Striker wrote:
[...]
Apache has always done this kind of thing in the default config;
GET a file with a .tar.gz extension and the response has
Content-Encoding: x-gzip, Content-Type: application/x-tar.
I think it's safest for neon to ignore anything other than the
gzip content-coding, given that the only content-coding sent in
the accept-encoding request header is gzip.
Won't that break things if somebody has a .tar.gz file that isn't
in subversion and a neon-based client tries to download it? Neon
should be uncompressing this file,
*surprised* Should it? If that is in the spec I now know who to
blame for IE behaviour I so hate. When downloading a tarball, I
want to save it as is (any clue how to run pgp/md5sum over it if it
is already decompressed before it hits my disk?).
I'm afraid that's how it seems - I have been bitten by this many
times.
If we would live in a perfect world, a file specified with
Content-Type: application/gzip would be saved as is, since that's all
the information we have on a compressed file - on the other hand
Content-type: something/else and Content-Encoding: gzip (and x-gzip)
would be automatically decompressed on the fly, since that would imply
that the compression is only an intermediate transformation applied
and supposed to be removed.
Unfortunately, application/gzip doesn't exist, and the behaviour isn't
what we see, nor does it seem to agree with the RFCs we have on the
matter.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:05:41 2006