Re: HTTP/2 GREASE, Results, and Implications

[Tom Bergan <[e-mail]>]

I would like to revisit the ambiguity that Willy pointed out in this
thread. On the one hand, we have this statement, which appears in Sections
4.1 and 5.5:

1. Implementations MUST discard frames that have unknown or unsupported
types.

On the other hand, we have statements like the following, which appear in
Section 5.1:

2a. idle: Receiving any frame other than HEADERS or PRIORITY on a stream in
this state MUST be treated as a connection error.

2b. half-closed (remote): If an endpoint receives additional frames, other
than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this
state, it MUST respond with a stream error

If this ambiguity is resolved in favor of Section 5.1, then it becomes
difficult or impossible to define a new priority scheme in an HTTP/2
extension. In particular:

- It might be desirable to send a NEW_PRIORITY frame before HEADERS, as a
replacement for priority information that is built into HEADERS. This
conflicts with (2a).

- It might be desirable to send a NEW_PRIORITY frame after END_STREAM, so
the client can reprioritize a lengthy response. This conflicts with (2b).

For this reason, I propose that this ambiguity should be resolved in favor
of Section 5.5. We should release an errata which clarifies that the rules
in Section 5.1 do not apply to frames of unknown type. If an extension
defines a new frame type, it must explicitly enumerate the states in which
that frame can be sent and received. Willy also raised a concern about new
frame types that include END_STREAM. I think this is covered by Section
5.5, which says "Extensions that could change the semantics of existing
protocol components MUST be negotiated before being used." If a new frame
type can end the stream, this adds an edge to the state diagram in Section
5.1, therefore, support for the new frame type must be negotiated before it
can be used.

Thoughts?

On Wed, Nov 6, 2019 at 12:27 PM Willy Tarreau <[e-mail]> wrote:

> Hi Bence,
>
> On Wed, Nov 06, 2019 at 03:03:18PM -0500, Bence Béky wrote:
> > Hi,
> >
> > I added two simple command line flags to Chrome to trigger sending
> greased
> > HTTP/2 elements, and they are available since version 80.0.3960.0 (not on
> > Linux quite yet).
>
> OK, thanks for letting us know.
>
> > --http2-grease-settings adds one settings parameter with a reserved
> > identifier and random value to every SETTINGS frame sent (one per HTTP/2
> > connection).
> >
> > --http2-grease-frame-type sends one frame of reserved type and random
> short
> > payload after every SETTINGS and HEADERS frame, including HEADERS frames
> > with END_STREAM flag set.  This is what caused problems apparently with
> > Cloudflare and Akamai.
>
> And haproxy, given that this violates the rule of no frame type other than
> the few allowed one in half-closed remote state. The problem with allowing
> new frame types during forbidden states is that we could make it way
> harder to implement these new frame types later without risking to see
> them behave differently depending on implementations. I suspect that if
> we want to go down that route we'll need to either reserve certain frame
> types as carrying no payload for streams and others as possibly having
> some :-/ In addition, frame flags are defined per-frame, eventhough we
> all know they are the same. But new frames exhibiting an END_HEADERS
> flag or an END_STREAM flag cannot be completely ignored. Frames
> designating an idle stream ID which are not HEADERS frame will also
> possibly create a stream or not and cause issues. I think that at the
> moment the only way we have to continue to ignore frames is :
>
>   - ignore the unknown ones on stream 0
>   - ignore the unknown ones on non-idle, non-half-closed(remote) streams
>   - respect existing rules for existing states (i.e. reject what doesn't
>     match certain types for idle, half-closed, reserved.
>   - and likely define how to deal with known flags in the remaining
>     cases.
>
> Just my two cents.
>
> Cheers,
> Willy
>
>