[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tomcat-user
Subject:    Tomcat 10 with Http2 and compression sometimes closes connection with Firefox
From:       "Thomas Hoffmann (Speed4Trade GmbH)" <Thomas.Hoffmann () speed4trade ! com ! INVALID>
Date:       2022-06-26 14:59:26
Message-ID: 59583e9bdb754596b375a5da7b0e2c54 () speed4trade ! com
[Download RAW message or body]

Hello Mark,
few months ago we already discussed an issue with http2 and compression. The old \
title was "Many IllegalStateException when using http2 protocol". I start from \
scratch so nobody needs to lookup old stuff and first I want to summarize the old \
discussion and then add the new gathered information.

Problem: 
When opening a webpage at a new Tab, Firefox sometimes doesn't load the full page \
from Tomcat 10

Observation / Circumstances:
- Doesn't happen with Tomcat 9 (tested up to 9.0.64)
- Problem showed up after upgrading from Tomcat 9.0.56 to 10.0.16
- Tomcat 10.0.16 also showed a stacktrace in the logfile
   07-Mar-2022 07:24:01.780 SCHWERWIEGEND [https-openssl-nio-443-exec-21] \
org.apache.catalina.core.ApplicationDispatcher.invoke Servlet.service() for servlet \
[jsp] threw exception  java.lang.IllegalStateException: Connection [66], Stream \
[113], Unable to write to stream once it has been closed  at \
org.apache.coyote.http2.Stream$StreamOutputBuffer.doWrite(Stream.java:843)  at \
org.apache.coyote.http11.filters.GzipOutputFilter$FakeOutputStream.write(GzipOutputFilter.java:159)
  at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:252)
  at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:210)
  at java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148)
		at org.apache.coyote.http11.filters.GzipOutputFilter.doWrite(GzipOutputFilter.java:69)
  at org.apache.coyote.http2.Http2OutputBuffer.doWrite(Http2OutputBuffer.java:59)
		at org.apache.coyote.Response.doWrite(Response.java:625)
		at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:340)
		at org.apache.catalina.connector.OutputBuffer.flushByteBuffer(OutputBuffer.java:783)
  at org.apache.catalina.connector.OutputBuffer.realWriteChars(OutputBuffer.java:453)
		at org.apache.catalina.connector.OutputBuffer.flushCharBuffer(OutputBuffer.java:788)
  at org.apache.catalina.connector.OutputBuffer.append(OutputBuffer.java:727)
		at org.apache.catalina.connector.OutputBuffer.write(OutputBuffer.java:505)
		at org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:148)
		at org.apache.catalina.filters.ExpiresFilter$XPrintWriter.write(ExpiresFilter.java:850)
  at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
		at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
		at org.apache.jasper.runtime.JspWriterImpl.write(JspWriterImpl.java:275)
		at java.base/java.io.PrintWriter.write(PrintWriter.java:506)
		at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:112)
		at org.apache.jasper.runtime.JspWriterImpl.flush(JspWriterImpl.java:160)
		at org.apache.jsp.WEB_002dINF.jsp.businessrelations.ticket_005frelations_inc_jsp._jspService(ticket_005frelations_inc_jsp.java:702)
                
		...
- The stack is probably related but not the cause of the issue
- The stacktrace was not logged any more with Tomcat 10.0.18 (but problem stayed)
- The problem only occurs with HTTP2
- It also only occurs when http compression is activated (compression="force" or \
                "on")
- a provided debug-log of HTTP2 (loglevel FINE) didn't narrow down the issue


This week I found time for digging down into the rabbit hole and also was able to \
create an almost static application.

I did several network traces and it followed the following scheme:
1) Main page was requested by Firefox from Tomcat (GET ...)
2) Tomcat sends the first compressed chunks of data to the browser
3) Firefox reads the first packages and notices, that additional resources are needed \
(CSS, JS ...) 4) While Tomcat is still sending the main page in chunks, the browser \
is already requesting additional resources on other channels 5) Firefox is sending a \
RST_STREAM and closes that last requested stream(s)  (dunno why it does request first \
and then closes the channel) 6) Tomcat is sending a GoAway message to the browser
7) Tomcat stops also sending the main page (on a different channel)

Shouldn't tomcat just close the requested stream and continue serving the other \
stream(s)? Looks like Tomcat got upset and also closed the other stream :)

Pcap-file is available at \
https://privfile.com/download.php?fid=62b8721f9f29a-MTM1NTk=  for around 2 weeks. I \
could also provide an almost static app which relatively often shows this issue \
(after several trials). As it contains some internal CI and stuff, I could sent it to \
a personal address. I tested with Win10 and Win11, FF 101, Tomcat 10.0.16

Thanks in advance!
Thomas






---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]