Re: [cp-patches] Patch: fix Content-Encoding for compressed HTTP responses

[David Daney]

Tom Tromey wrote:
> > > > > > "Anthony" == Anthony Green <address@hidden> writes:
>
>
> Anthony> I found this while debugging Azureus.  We automatically decompress
> Anthony> compressed HTTP responses, but still report them as having compressed
> Anthony> content.   This patch removes the Content-Encoding header in these
> Anthony> cases.  This appears to be what Sun does in these cases.  Ok?
>
> When I run that case program, if I specify that it should ask for a
> gzip encoding, Sun's protocol handler hands back a gzipped stream --
> i.e., it does not uncompress.
>
> I think either behavior is correct, since user code has no way of
> knowing whether it should have gotten a zipped stream.  But I
> wonder... Sun's behavior seems a bit nicer since it allows the option
> of not uncompressing, if that is what is wanted.

I would have to study the relevant specifications in more depth, but 
this seems like a good idea.  If the caller explicitly sets an 
Accept-Encoding of gzip or deflate, we should probably just send the 
data on through as is.  Otherwise do the decoding in the runtime as we 
currently do.

RFC 2616 section 14.3 seems to be the controlling-legal-authority here. 
 It implies that if there was no Accept-Encoding specified, then the 
server is free to send anything it wants to.  In this case we should 
probably handle any gzip or deflate Content-Encodings found.

If Accept-Encoding is specified we would probably not handle automatic 
decoding.

> Also I wonder about throwing an exception if we don't recognize the
> content-encoding.  It seems to me that the caller might well recognize
> it somehow.

How would you make this behavior compatible with java.net.*?

What exception would you throw?

What state would the connection be in after throwing?

David Daney.