W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 9 Aug 2013 02:04:58 +0200
Message-ID: <CABkgnnX6X1JihDo2di3VfEMtmCi7zDi-FUaVWedpX4TaE7uxMg@mail.gmail.com>
To: Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>
Cc: William Chan <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
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
> >>> >
> >>> >
> >>
> >>
> >
>
Received on Friday, 9 August 2013 00:05:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC