- 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