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

[Chris Hegarty]

> On 15 Apr 2020, at 18:17, Daniel Fuchs <daniel.fuchs at oracle.com> wrote:
> 
> Hi Chris,
> 
> On 15/04/2020 17:40, Chris Hegarty wrote:
>> 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.
> 
> That does not make sense. If there is END_STREAM there cannot
> be any continuation frames since the stream will be closed.

From section 6.2 - HEADERS: 

   END_STREAM (0x1):  When set, bit 0 indicates that the header block
      (Section 4.3 <https://tools.ietf.org/html/rfc7540#section-4.3>) is the last that the endpoint will send for the
      identified stream.

      A HEADERS frame carries the END_STREAM flag that signals the end
      of a stream.  However, a HEADERS frame with the END_STREAM flag
      set can be followed by CONTINUATION frames on the same stream.
      Logically, the CONTINUATION frames are part of the HEADERS frame.

-Chris.

[1] https://tools.ietf.org/html/rfc7540#section-6.2

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/net-dev/attachments/20200415/1f2f38d0/attachment.htm>