[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: <joe_at_manyfish.co.uk>
Date: 2003-01-21 22:39:57 CET

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:
   What happens is that neon is transparently decompressing the response since
   it has Content-Encoding: x-gzip in the header. Note that you don't need
   mod_deflate triggered (I don't think it would compress twice because it
   tries to prevent this). Therefore, Subversion gets a truly corrupt file -
   it's uncompressed when it's not really supposed to be.
   ne_compress.c line 247 has:
   if (ctx-enchdr strcasecmp(ctx-enchdr, gzip) == 0) {
   x-gzip matches. Perhaps it'd be nice if we could get neon to only
   recognize 'gzip' rather than 'x-gzip.' I don't know if that's legal or not.
  Are you sure that is right? That strcasecmp won't match x-gzip.
  On the legality: there is a SHOULD requirement in 2616 that x-gzip is
  treated equivalent to gzip but if everything else you said is right,
  you would seem to have provided a good rationale for *not* treating
  x-gzip and gzip the same...
 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.


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