8189789: tomcat gzip-compressed response bodies appear to be broken in update 151

[Hohensee, Paul]

If the fix is from the zlib project, then ignore the following, since it’s their code.

In Deflater.c: the existing significant code duplication between the arms of the if-else gives one pause. E.g., in the new file, compare lines 148/183 and 155/190. Might be bugs lurking at 183 and 190.

In deflate.c: the old code had “s->last_flush = Z_NO_FLUSH”, the new has “-2”. Should “-2” be symbolic instead?

Thanks,

Paul

On 11/22/17, 2:00 AM, "core-libs-dev on behalf of Seán Coffey" <core-libs-dev-bounces at openjdk.java.net on behalf of sean.coffey at oracle.com> wrote:

    Looking to fix a recent regression that appeared in 8u151. Thanks goes 
    to Sherman for the src patch. Paul Hohensee has also helped by provided 
    some test code. I've been able to modify an existing test to mimic the 
    behaviour seen with FlushableGZIPOutputStream which is found in Tomcat 7.x.
    
    Sherman is working on a patch for JDK 10. For unix OSes, JDK 10 operates 
    with the zlib version found on the OS.
    
    bug : https://bugs.openjdk.java.net/browse/JDK-8189789
    webrev : http://cr.openjdk.java.net/~coffeys/webrev.8189789.jdk8u/webrev/
    
    regards,
    Sean.