- From: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
- Date: Wed, 7 Aug 2013 23:23:28 +0900
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAPyZ6=KuzfquV8Q8RS3RtHX8SsLNtbA3oHCTN6sdqVvyzcn5rQ@mail.gmail.com>
Hi, Section 5.1. Stream States says that: """ closed: 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