HTTP/2 responses with Content-Length may have no content #12249
Assignees
Labels
Bug
For general bugs on Jetty side
Comments
sbordet
added a commit
that referenced
this issue
Sep 8, 2024
Fixed HttpReceiverOverHTTP2.read() to return a failed chunk if the stream has been reset. This closes the window where a RST_STREAM frame may be received, drain the DATA frames in HTTP2Stream, and the application reading exactly at that point. Signed-off-by: Simone Bordet <simone.bordet@gmail.com>
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
Jetty version(s)
12
Description
Since #10655, a RST_STREAM frame may drain unread DATA frames in
HTTP2Stream.It is possible that the server sends a good response with content, but fails to fully read the request content, and this results in a RST_STREAM to be sent to the client.
The client may see the response headers, possibly indicating a
Content-Lengthheader with a positive value, but may decide to read the response content later.This results in the DATA frames to be queued in the stream, but then the RST_STREAM drains them.
There is a small window between draining the DATA frames and notifying the upper layer that a RST_STREAM was received.
If an application tries to read during that small window, it reads an EOF chunk, rather than a failure chunk, and it may think the response was successful and had no content, even if the
Content-Lengthheader indicated that there was content.This is the reason for the flakyness reported by #11960.
The text was updated successfully, but these errors were encountered: