When applying GZIP compression, no Content-Length header should be set as the response size cannot be determined in advance. CompressionConfig.useCompression therefore calls response.setContentLength(-1). The behaviour I am seeing, is that with Http2 and GZIP compression, I still get a Content-Length header, but for the original response size. This causes all kinds of weird quirks in browsers when it comes to caching resources (as the browser cannot reliably determine the resource size, it will no cache the resource). The Http11Processor.prepareResponse() method first sets up compression, and then sets the Content-Length. The HTTP2 StreamProcessor.prepareResponse() call StreamProcessor.prepareHeaders(...) and that one does this stuff in the wrong order: it first sets the content-length header and then sets up compression.
Thanks for the report. I'm surprised the clients didn't reject the response entirely. Fixed in: - master for 10.0.0-M5 onwards - 9.0.x for 9.0.35 onwards - 8.5.x for 8.5.55 onwards
Thanks for the fix! Yes, I was wondering about that too, IIRC the spec requires clients to drop such invalid responses.