W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Connection-level flow control and DATA frame against closed state streams

From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Date: Wed, 7 Aug 2013 23:23:28 +0900
Message-ID: <CAPyZ6=KuzfquV8Q8RS3RtHX8SsLNtbA3oHCTN6sdqVvyzcn5rQ@mail.gmail.com>
To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>

Section 5.1. Stream States says that:

      The "closed" state is the terminal state.

      An endpoint MUST NOT send frames on a closed stream.  An endpoint
      that receives a frame after receiving a RST_STREAM or a frame
      containing a END_STREAM flag on that stream MUST treat that as a
      stream error (Section 5.4.2) of type STREAM_CLOSED.

      If this state is reached as a result of sending a RST_STREAM
      frame, the peer that receives the RST_STREAM might have already
      sent - or enqueued for sending - frames on the stream that cannot
      be withdrawn.  An endpoint that sends a RST_STREAM frame MUST
      ignore frames that it receives on closed streams after it has sent
      a RST_STREAM frame.  An endpoint MAY choose to limit the period
      over which it ignores frames and treat frames that arrive after
      this time as being in error.

My understanding is that DATA frames received in this closed state is still
under the connection-level flow control. This may be obvious because the
sender of DATA frame may send those frames before got RST_STREAM from the
remote and could not re-calculate connection-level window after RST_STREAM
was received.
But stating that explicitly in this section helps implementers and is a
good note for the test case.
Maybe just like this:

A flow controlled frame received in this state is still subject to the
connection-level flow control.

Best regards,

Tatsuhiro Tsujikawa
Received on Wednesday, 7 August 2013 14:24:15 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC