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

This doesn't affect the sender, but the receiver does need to account
for this.  The proposed statement loses that little gotcha.  Can you
raise an issue for this?  I'll see if I can make it a little bit
clearer.

On 7 August 2013 16:23, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com> wrote:
> 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 15:46:11 UTC