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

2013/08/08 3:43 "William Chan (陈智昌)" <willchan@chromium.org>:
>
> 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.
>

+1 to DATA frames are always under connection flow control irrespective of
the stream state.

Best regards,

Tatsuhiro Tsujikawa

>
> 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
>>> >
>>> >
>>
>>
>