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

Paul Sandoz paul.sandoz at oracle.com
Fri Dec 1 23:40:55 UTC 2017


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 ZBUFERROR. 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 ZBUFERROR. 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



More information about the core-libs-dev mailing list