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

Daniel Fuchs dfuchs at openjdk.org
Wed Feb 22 14:11:48 UTC 2023


On Wed, 22 Feb 2023 14:03:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> 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?
>
>> 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.
> 
> Good point. Maybe we should check whether requestBodyCF.isDone(), and if not, complete the requestBodyCF exceptionally before falling through to the rest of the code (checking isDone() is just an optimization to avoid creating the IOException if it's going to be ignored).

> Also, if we receive the reset frame as the first frame on the stream, shouldn't we complete exceptionally, like we do today?

I don't think that has changed. Even if we complete the requestBodyCF with null (which means stop sending / request body successfully sent) then the reading of the response body will kick in, and we will process the reset frame inserted in the inputQ at that point.

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

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


More information about the net-dev mailing list