RFR JDK-8191918: tomcat gzip-compressed response bodies appear to be broken in update 151

[Paul Sandoz]

> On 30 Nov 2017, at 14:46, Xueming Shen <xueming.shen at oracle.com> wrote:
> 
> Hi,
> 
> Please help review the change for  JDK-8191918:
> 
> issue: https://bugs.openjdk.java.net/browse/JDK-8191918
> webrev: http://cr.openjdk.java.net/~sherman/8191918/webrev
> 

InflateIn_DeflateOut.java
—

 174         GZIPInputStream gzis = new GZIPInputStream(byteInStream);
 175         ByteArrayOutputStream baos = new ByteArrayOutputStream();
 176         int numRead;
 177         byte[] b = new byte[4 * 1024];
 178         try {
 179             while ((numRead = gzis.read(buf)) >= 0) {
 180                 baos.write(b, 0, numRead);
 181             }
 182         } finally {
 183             baos.close();
 184         }

Can you use gzis.transferTo(baos)?

Paul.

> This is the backport/identical change we have already putback into earlier update
> releases for JDK-8189789. It includes two changes
> 
> (1) to replace the change we put into jdk9 for #8184306 with the "official"
> change currently in zlib github repo (https://github.com/madler/zlib/issues/275)
> 
> http://cr.openjdk.java.net/~sherman/8184306
> https://bugs.openjdk.java.net/browse/JDK-8184306
> 
> (2) to change the way we handle the returned result Z_BUF_ERROR. Now the
> implementation expects that there might be bytes read from the input and bytes
> written to the output buffer when the deflateParams()/deflate() returns
> Z_BUF_ERROR. It is "interpreted as there is no enough buffer space for all output,
> but the deflater has decoded input bytes and write out output bytes as many as
> possible, come back with more available output space".
> 
> See related github/zlib discussions at #275 [1] and #305[2]
> 
> Thanks,
> Sherman
> 
> [1] https://github.com/madler/zlib/issues/275
> [2] https://github.com/madler/zlib/issues/305