W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2019

Re: HTTP/2 GREASE, Results, and Implications

From: Bence Béky <bnc@chromium.org>
Date: Fri, 1 Nov 2019 07:43:51 -0400
Message-ID: <CACMu3toue60Y_6Qxpzsqw-fOByc3Qjv=AG8Ed_DGvkR1EYn+4w@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Hi Willy,

Yes, I agree with you.  My current plan is to make Chrome send a frame of
reserved type
* on stream 0, after the SETTINGS frame;
* on non-zero streams, after each HEADERS and DATA frame that does not have
the END_STREAM flag set;
* or alternatively, after each HEADERS and DATA frame, and if the stream
should be closed, then send an empty DATA frame with END_STREAM after the
reserved frame.

I think this conforms to the state transition requirements you summarized.
Thank you for the guidance.  I'll keep the list posted.



On Thu, Oct 31, 2019 at 4:35 PM Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Oct 31, 2019 at 01:08:53PM -0400, Bence Béky wrote:
> > Thanks, Willy, for pointing out the different sections of RFC7540
> > concerning unknown frame types.  It seems to me that for the past few
> days
> > Chrome (on certain channels) has been sending frames on half-closed
> > (remote) streams.
> Bence, I saw that you updated the issue regarding this point. If
> you're going to be stricter on the states to respect the (confusing)
> wording of the spec, then you need to be very careful about other states
> for completeness:
>   - closed: An endpoint MUST NOT send frames other than PRIORITY on a
> closed
>     stream.
>   - reserved (remote): An endpoint MUST NOT send any type of frame other
>     than RST_STREAM, WINDOW_UPDATE, or PRIORITY in this state.
>   - idle: Receiving any frame other than HEADERS or PRIORITY on a stream in
>     this state MUST be treated as a connection error.
> I think it's reasonable to assume that only these transitions (in addition
> to the already mentioned half-closed) face such restrictions. This means
> that any new non-negociated frame type will still be allowed for the
> connection (stream 0) and open streams. This sounds quite reasonable and
> should not risk to trigger the consistency issues in the spec's wording.
> And at first glance if that's the case I don't need to patch my code,
> so we can expect that other implementations faced similar issues and
> that the limitations above remain acceptable (but an errata will have
> to be filed to keep track of this).
> Hoping this helps,
> Willy
Received on Friday, 1 November 2019 11:44:06 UTC

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