[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:09:35 CET

On Tue, 21 Jan 2003, Joe Orton wrote:
 On Tue, Jan 21, 2003 at 12:54:06PM -0800, Greg Stein wrote:
  On Tue, Jan 21, 2003 at 08:03:02PM +0000, Joe Orton wrote:
   On Mon, Jan 20, 2003 at 04:53:35PM -0800, Justin Erenkrantz wrote:
  Um, isn't the server in the wrong here? It seems like it should not have
  included the Content-Encoding header in there. That *tells* the client to
  un-apply the transformation.
  Looking at section 14.11 of RFC 2616, it specifically states that the client
  should remove the encodings to arrive at the proper content (of the type
  described by Content-Type).
  So... I'd say Neon should be fixed to recognize both gzip and x-gzip.
  And Justin should fix his server configuration :-)

 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, the server needs to be smart enough to _not_ add
the gzip content-encoding to compressed files that are within subversion.
I would go so far as to say that mod_dav_svn should remove all
content-encodings in the fixups phase (but I haven't thought through all
of the implications of that).

That would allow mod_deflate to work (because that content-encoding is
added in a filter), and it would fix the case that Justin is reporting.
Essentially, any data in a subversion repository is just that, data.

The only draw-back, is that I believe this would actually stop you from
serving pages directly out of a subversion repository. hmmmmmm.......


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