RFR: 8309118: HttpClient: Add more tests for 100 ExpectContinue with HTTP/2 [v6]

[Daniel Fuchs]

On Thu, 19 Oct 2023 12:36:22 GMT, Conor Cleary <ccleary at openjdk.org> 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