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

Re: HTTP/2 GREASE, Results, and Implications

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 31 Oct 2019 21:34:58 +0100
To: Bence Bky <bnc@chromium.org>
Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20191031203458.GA31017@1wt.eu>
On Thu, Oct 31, 2019 at 01:08:53PM -0400, Bence Bky 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
  - 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,
Received on Thursday, 31 October 2019 20:35:06 UTC

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