Re: HTTP/2 GREASE, Results, and Implications

[Bence Béky <[e-mail]>]

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.

Cheers,

Bence

On Thu, Oct 31, 2019 at 4:35 PM Willy Tarreau <[e-mail]> 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
>