- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 31 Oct 2019 21:34:58 +0100
- To: Bence Béky <bnc@chromium.org>
- Cc: Mike Bishop <mbishop@evequefou.be>, HTTP Working Group <ietf-http-wg@w3.org>
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 Thursday, 31 October 2019 20:35:06 UTC