https://bz.apache.org/bugzilla/show_bug.cgi?id=64974
Bug ID: 64974
Summary: Tomcat losing HTTP pipeline requests is asking for
available bytes
Product: Tomcat 9
Version: 9.0.38
Hardware: PC
OS: Mac OS X 10.1
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: cy6erg...@gmail.com
Target Milestone: -----
Created attachment 37599
--> https://bz.apache.org/bugzilla/attachment.cgi?id=37599&action=edit
Just before the fill will discard requests (in debugger)
Starting from 9.0.39 Tomcat server does lose pipelined HTTP requests.
The scenario is the following:
1. A client connects and send a single packet of two HTTP requests
2. The server accepts connection, reads the bytes, parses the first request,
does aux tasks, and notifies a servlet by calling the service method. At this
point, Http1InputBuffer contains both requests, but the first is processed, so
the position points to the beginning of the second request (that is not yet
processed/parsed).
3. The called servlet does start async, start a new thread, and then does setup
read listener.
4. setReadListener function invocation leads to the following call chain:
setReadListener -> CoyoteInputStream.setReadListener ->
InputBuffer.setReadListener -> InputBuffer.isReady -> Request.action
(NB_READ_INTEREST) -> AbstractProcessor.action ->
AbstractProcessor.isReadyForRead -> Http11Processor.available ->
Http11InputBufer.available -> Http11InputBuffer.fill
The fill function checks for the "parsingHeader" flag and goes to the
alternative branch. The byte buffer still contains both requests, and the
position is pointing to the beginning of the second request. However, the
alternative branch does change both position and limit to the same value losing
the right end position. After that, the fill function does several preparation
and invokes socket.read that overwrites the second request or read nothing but
the second request is lost forever because the end position was lost.
See the attached screenshot of this moment.
It looks like the code lading to the issue was there for a long time, but due
to some changes in 9.0.39, it started to happen. But for sure, the fill
function shouldn't simply discard the limit position but should append bytes
after the limit regardless of the "end" value that points to the last parsed
request that is not correct.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
