On Thu, 19 Oct 2023 12:36:22 GMT, Conor Cleary <[email protected]> wrote:
>> ### **Issue Description**
>> There is missing test coverage for the implementation of
>> partial/informational responses (status code 1xx in server response headers)
>> for the `HttpClient`, specifically in the `HTTP/2` use case. RFC 9113 -
>> HTTP/2, details the behavior of any client in these situations. Small
>> changes and new test cases are needed to verify compliance with this
>> specification. This issue primarily concerns how the client reacts to
>> receiving a `RST_STREAM` frame at various stages of a partial/informational
>> response from a server.
>>
>> ### **Solution Details**
>> Changes were made in
>> `src/java.net.http/share/classes/jdk/internal/net/http/Stream.java` to
>> improve the handling client's handling of receiving a `RST_STREAM`.
>> `incoming_reset()` (L574) will now cause the client to ignore a `RST_STREAM`
>> frame if an `END_STREAM` flag has been received _and_ the request body has
>> completed sending. Previously it would be ignored only if an `END_STREAM`
>> flag was seen which caused cancelled partial responses to 'hang'
>> indefinitely should a client be transmitting data in a POST/PUT request. An
>> overhaul of how `incoming_reset()` was done in an effore to simplify the
>> method and make it easier to debug in the future.
>>
>> Some changes where also made to the `schedule()` method in Stream (L190) to
>> ensure both the sending of the Request Body and receipt of a RST_STREAM at
>> various stages of an exchange do not cause unexpected behavior. Minor
>> changes were made to the `Http2TestServer` implementation to improve the
>> convinience of testing edge cases involving the sending of `HTTP/2` response
>> headers.
>>
>> Concerning the new test cases, I have listed below the specifics of each
>> case and the expected behavior of the client in the given scenario.
>>
>> **test/jdk/java/net/httpclient/ExpectContinueTest.java**
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>> - Server responds with a `HEADERS` frame including a 100 status code.
>> Server then sends `RST_STREAM` with code `NO_ERROR` or `PROTOCOL_ERROR` set
>> before an END_STREAM is received from the server.
>> - Expected/Observed Client Behavior: Client completes exceptionally
>> in both cases.
>> - Client sends a POST request with the `Expect: 100-Continue` header included
>> - Server responds with a `HEADERS` frame including a 100 status code and
>> reads the request body. Server then sends Response Headers with status code
>> 200 to complete the response. Server then sends RST_STREAM with code `N...
>
> Conor Cleary has updated the pull request incrementally with one additional
> commit since the last revision:
>
> schedule completes normally on NO_ERROR, incoming_reset safely accesses
> volataile
Hi @c-cleary this mostly look good to me now. I do have one additional
suggestion though. There is a corner case where we may have received END_STREAM
but are still expecting some frames: that's the case of CONTINUATION frames: in
that case the END_STREAM is carried by the HEADERS frame, and the END_HEADERS
will be carried by a continuation frame that follows. If we receive a RESET at
that point, we should also handle it immediately and relay an exception to the
caller. I believe that could be easily handled by handling reset immediately
also in the case where `finalResponseCodeReceived` is `false`. See suggestion
below.
src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 619:
> 617: }
> 618: if (!endStreamSeen) {
> 619: // If no END_STREAM flag seen, any RST_STREAM should be
> handled here immediately
Suggestion:
if (!endStreamSeen || !finalResponseCodeReceived) {
// If no END_STREAM flag seen, any RST_STREAM should be handled
here immediately
// If the final response code was not received, then we should
also handle
// the RST_STREAM immediately
-------------
Changes requested by dfuchs (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/15664#pullrequestreview-1692682442
PR Review Comment: https://git.openjdk.org/jdk/pull/15664#discussion_r1368747707
