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 :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
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:04:55 2006