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

This is a great catch of something that is not well explained in the spec.
I suspect many implementations might have this bug. When discussing this
earlier, I wondered if a simplification might be to note that received DATA
frames are always under connection flow control, irrespective of stream
state? If the DATA frame was incorrectly sent, that might be a reason to
send an error and even terminate the connection, but I don't believe that
changes whether or not it should be counted towards the connection flow
control window.


On Wed, Aug 7, 2013 at 8:54 AM, Tatsuhiro Tsujikawa
<tatsuhiro.t@gmail.com>wrote:

>
>
>
> On Thu, Aug 8, 2013 at 12:45 AM, Martin Thomson <martin.thomson@gmail.com>wrote:
>
>> 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.
>>
>>
> Sure. https://github.com/http2/http2-spec/issues/225
>
> Best regards,
>
> Tatsuhiro Tsujikawa
>
>
>>  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
>> >
>> >
>>
>
>