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

[Conor Cleary]

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

>>> 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.

> 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?

You are correct in your observation here, this does indeed cause the bug to resurface as you said it would. I agree with Daniel's assessment of what should be done instead WRT checking if `requestBodyCF.isDone()` and it does fix the issue.

After testing and adjusting of the comment as mentioned, I'll publish that change if all is well.

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

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