>>>>> "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. 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. 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. Comments? Tom _______________________________________________ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
