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

I added text addressing the original issue on the train, but this sounds
like a much better proposal. Consider it done for -05.
On Aug 7, 2013 5:53 PM, "Tatsuhiro Tsujikawa" <tatsuhiro.t@gmail.com> wrote:

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