[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Problem with checksums...

From: <naked_at_iki.fi>
Date: 2003-01-22 00:51:29 CET

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

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

-- 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.