I found this while debugging Azureus. We automatically decompress
compressed HTTP responses, but still report them as having compressed
content. This patch removes the Content-Encoding header in these
cases. This appears to be what Sun does in these cases. Ok?
tromey: I would also like to
Anthony == Anthony Green [EMAIL PROTECTED] writes:
Anthony I just want to get this patch into rawhide. My feeling is that it
Anthony solves an incompatibility, and introduces no regressions.
I agree, it is the minimal required improvement. Please check it in.
I think what we want to do is
On Mon, 2006-01-16 at 10:52 -0700, Tom Tromey wrote:
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 didn't even notice this option!
I think either behavior is correct,
David == David Daney [EMAIL PROTECTED] writes:
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.
David How would you make this behavior compatible with java.net.*?
David What exception would
Anthony == Anthony Green [EMAIL PROTECTED] 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.
On Mon, 2006-01-16 at 12:49 -0700, Tom Tromey wrote:
Anthony == Anthony Green [EMAIL PROTECTED] writes:
Anthony I just want to get this patch into rawhide. My feeling is that it
Anthony solves an incompatibility, and introduces no regressions.
I agree, it is the minimal required
Tom Tromey wrote:
Anthony == Anthony Green [EMAIL PROTECTED] 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
