RFR: 8293786: HttpClient will not send more than 64 kb of data from the 2nd request in http2

[Daniel Jeliński]

On Wed, 22 Feb 2023 12:37:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.net.http/share/classes/jdk/internal/net/http/Stream.java line 556:
>> 
>>> 554:             Flow.Subscriber<?> subscriber =
>>> 555:                     responseSubscriber == null ? pendingResponseSubscriber : responseSubscriber;
>>> 556:             if (frame.getErrorCode() == ResetFrame.NO_ERROR) {
>> 
>> We should stop sending regardless of the error code provided. 
>> https://www.rfc-editor.org/rfc/rfc9113#name-rst_stream does not mention any special handling for specific error codes.
>
> But only in case of NO_ERROR should we complete the requestBodyCF successfully.
> In other cases, the reception of the reset frame should be considered as an error. 
> There is also a subtle issue as to *when* the reset frame should be processed, and if it comes after we have started processing DataFrames we should not be processing it before we have processed the DataFrames that came before. These cases are handled below, in handleReset/receiveResetFrame.
> 
> @c-cleary could you please improve the comment here to explain what we're doing, and quote the relevant part of the spec (the paragraph that explains that a server may send a RESET frame with NO_ERROR *after* having sent the complete response if it doesn't need the request body to handle the response)?

ah, I didn't check the surrounding code.
Unless I'm missing something, if we receive a data frame followed by a reset with error code other than NO_ERROR, we will still run into this bug: incoming_reset will only enqueue the reset frame and do nothing else.
Also, if we receive the reset frame as the first frame on the stream, shouldn't we complete exceptionally, like we do today?

-------------

PR: https://git.openjdk.org/jdk/pull/12694