On 15/12/2022 22:42, Lorenzo Dalla Vecchia wrote:
<snip/>
I looked at the sources for the HTTP/2 connector and found this code
around line 100 of org.apache.coyote.http2.StreamProcessor.
StreamException se = new StreamException(
sm.getString("streamProcessor.cancel", stream.getConnectionId(),
stream.getIdAsString()), Http2Error.CANCEL,
stream.getIdAsInt());
stream.close(se);
This seems to be the only place where the connector is sending a CANCEL
besides the forced closing of the connection in
org.apache.coyote.http2.Http2UpgradeHandler.close().
I don't know HTTP/2 deeply enough to say that sending CANCEL here is
wrong, also because I'm not sure I understand the situation that the
connector is addressing. However, could it be that the correct code here
shold be Http2Error.NO_ERROR?
I recompiled the class with that change, and my test case ran for 12
hours without fail.
There is also this bug report for the Go http2 package:
https://github.com/golang/go/issues/19948
It looks pretty similar to the problem we see here (except that, in that
case, the client is directly a browser).
The folks there conclude that the CANCEL error code is mostly intended
for clients and that servers should end "useless" streams with NO_ERROR.
They also quote a section of the RFC
(https://www.rfc-editor.org/rfc/rfc7540#section-8.1), but I am not sure
if it applies to the Tomcat case.
What do you think? Could this be a rare Tomcat bug, an httpd bug, or
something else?
Please let me know if you need more information.
The specification language isn't is tight as I'd like it to be but I
think you're right - the intention of the spec authors was that NO_ERROR
gets used here. I'll get that updated for the next round of releases.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
