[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: <rbb_at_rkbloom.net>
Date: 2003-01-21 23:33:41 CET

On Tue, 21 Jan 2003, 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?).

Yes, that is in the spec, and it is the way that we used to tell people to
get the advantages of mod_deflate without the disadvantages. Basically,
you compress all of your pages when you copy them to the server. This
removes the overhead of compressing the pages on the fly, and the client
is supposed to be smart enough to decompress the page after it is
received. The problem with IE is that it doesn't let you say Don't
decompress, I am going to move this file to another computer. :-)


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:21 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.