8238270: java.net HTTP/2 client does not decrease stream count when receives 204 response

[Daniel Fuchs]

Hi Chris,

>> The fix ensures that any pending data frame will still be processed
>> after 204 has been received - thus triggering the logic that
>> eventually closes the stream.
> 
> I suppose that a 204 response MUST have an END_STREAM
> in its final HEADERS / CONTINUATION frame, right?

I have rescanned the RFC. I could not find a definitive answer to
that question. AFAIU it's expected that the HEADERS frame will
carry the END_STREAM - but there is some sibylline text that let
me think that having an empty DATA frame carrying the END_STREAM
would be OK too:

<<< A response
    that is defined to have no payload, as described in [RFC7230],
    Section 3.3.2, can have a non-zero content-length header field, even
    though no content is included in DATA frames. >>>

> It is allowable for a HEADERS frame to carry an END_STREAM,
> but not an END_HEADERS. If this happens, then CONTINUATION
> frames must follow, the last of which will carry END_HEADERS.
> That probably explains why the END_STREAM handling is done
> the way that it is.

Yes. And the CONTINUATION frame is not supposed to carry the
END_STREAM - so we can see END_STREAM before END_HEADERS.
Therefore I have removed my changes to HeaderFrame.java.
Code inspection shows that we might not deal with that situation
properly - so I have logged https://bugs.openjdk.java.net/browse/JDK-8242999
to follow up on this.

> The new test is good, but has an unnecessary reference to
> AbstractThrowingSubscribers.TestExecutor.
>> https://bugs.openjdk.java.net/browse/JDK-8238270

Done.

New webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.01/

best regards, and thanks for the valuable feedback!

-- daniel

>>
>> webrev:
>> http://cr.openjdk.java.net/~dfuchs/webrev_8238270/webrev.00/index.html