Jetty 12.0.5 (ee10) throws IllegalStateException for completed requests when Gzip Handler is used #11095
Comments
minduch
changed the title
|
I am getting this too after updating from 12.0.4 to 12.0.5. I have been running 12.0.4 since it was released and never seen this but with 12.0.5 I get it every time. So it seems to be something new in 12.0.5. I can also confirm that it is somehow related to using the GzipHandler. Or at least that using the GzipHandler is one of the ways to trigger this. The filter is set up using this code private Handler wrapGzip(WebAppContext aWebContext)
{
if(isUseGZip )
{
GzipHandler loGzipHandler = new GzipHandler();
loGzipHandler.setHandler(aWebContext);
loGzipHandler.addIncludedMimeTypes(
"text/html",
"text/plain",
"text/xml",
"text/css",
"application/javascript",
"application/json",
"text/javascript");
loGzipHandler.addIncludedMethods("POST", "GET");
return loGzipHandler;
}
else
{
return aWebContext;
}
}And once I do this requests to static JS files cause the mentioned error in the logs Without wrapping the the Webappcontext with the GZipHandler everything is fine |
|
The code is correct, and it is indeed the |
…andler. Fixed 2 problems: * In ServletChannel, in COMPLETE state, there was a check comparing the number of bytes written with that declared by Content-Length. Unfortunately the check was wrong in case of gzip, because it was comparing the application length with the gzipped length, resulting in a late sendErrorOrAbort() that was an abort() because the response was already fully sent. Furthermore, if sendErrorOrAbort() was actually an abort(), there was an unnecessary attempt to complete the output. * In GzipHandlerResponseAndCallback there were 2 last writes: one when the application calls output.close(), and one when the callback is succeeded. Furthermore, when no content needs to be written, it was still compressed, causing an IOException in ChannelResponse (again when double-checking the bytes written, since Content-Length was 0, but the gzip header and trailer were written). Signed-off-by: Simone Bordet <[email protected]>
|
@sbordet The fix seems to work for me |
|
@sbordet It will probably work in my case too as it seems to be the same kind of error. When is 12.0.6 expected, and will it include this PR? |
|
12.0.6 expected by end of month, and yes will have this PR. |
|
@sbordet We are so "full up with work" that I think takes too long time to setup this PR test environment, so we will wait for 12.0.6 that will probably fix more stuff... Let's hope - it's a new year - BTW: Happy New Year! |
…Handler (#11210) * In ServletChannel, in COMPLETE state, there was a check comparing the number of bytes written with that declared by Content-Length. Unfortunately the check was wrong in case of gzip, because it was comparing the application length with the gzipped length, resulting in a late sendErrorOrAbort() that was an abort() because the response was already fully sent. Furthermore, if sendErrorOrAbort() was actually an abort(), there was an unnecessary attempt to complete the output. * In GzipHandlerResponseAndCallback there were 2 last writes: one when the application calls output.close(), and one when the callback is succeeded. Furthermore, when no content needs to be written, it was still compressed, causing an IOException in ChannelResponse (again when double-checking the bytes written, since Content-Length was 0, but the gzip header and trailer were written). * Updates semantic of when to add the "Vary" header. Now it is always only added by GzipHandler, when it would be possible to generate a response that might be compressed (even if it will not). * Added *.bz2 mime-type. Updated GzipHandler with the correct mime-type for *.bz2: application/x-bzip2. * Improved checks for the number of bytes written against declared content-length. This is necessary because welcome files are written by DefaultServlet (most of the times) bypassing the Servlet classes, using ServletContextResponse directly. Signed-off-by: Simone Bordet <[email protected]> Co-authored-by: Joakim Erdfelt <[email protected]>
github-project-automation
bot
moved this from 🏗 In progress
to ✅ Done
in Jetty 12.0.6 FROZEN
Jetty version(s)
12.0.5
I think this issue also exists for Jetty 12.0.4 (I know that we did not get it in 12.0.2 at least).
Jetty Environment
ee10
Java version/vendor
(use: java -version)openjdk version "17.0.9" 2023-10-17
OpenJDK Runtime Environment Temurin-17.0.9+9 (build 17.0.9+9)
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode, sharing)
OS type/version
Windows 11 Pro, actually any OS.
Description
A seemingly successfully completed requests for most resources in our implementation with Embedded Jetty 12.0.5 logs (perhaps with GZIP involved):
How to reproduce?
In our product "IIZI" with embedded Jetty 12.
The only piece of our code being run is shown below. The
handle(..)method is more used for internal debugging and passes on the execution into theorg.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:761).The code in
org.eclipse.jetty.ee10.servlet.ServletChannelState.java:1052seems to be the cause:Are we doing something wrong?
The text was updated successfully, but these errors were encountered: