Re: HTTP/2 GREASE, Results, and Implications

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.  It might be worth fixing that and re-running the
experiment.  I'll circle back with results if we end up doing that.

On Thu, Oct 31, 2019 at 11:55 AM Willy Tarreau <w@1wt.eu> wrote:

> Hi Mike!
>
> On Thu, Oct 31, 2019 at 03:09:34PM +0000, Mike Bishop wrote:
> > Way back when, I presented a draft
> > (https://tools.ietf.org/html/draft-bishop-httpbis-grease-00) proposing
> that
> > we adopt as an HTTP/2 extension the same behaviors that HTTP/3 is
> specifying,
> > permitting the greasing of settings and frame types.  The outcome of that
> > discussion was that, prior to considering adoption, we'd want to
> understand
> > the real-world impact of deploying such a behavior.  Bence generously
> > volunteered to add such an experiment to Chrome, which he has done.
> >
> > The results are discussed at https://crbug.com/1019410.  TL;DR:
> Settings are
> > fine, but too many servers blow up on unknown frame types for this to be
> > viable in major client deployments.  They don't even tell you what they
> don't
> > like - they just PROTOCOL_ERROR on you.
> >
> > Frankly, this makes me quite sad.  It means that our primary extension
> > mechanism for HTTP/2 has already rusted shut, and it's now inadvisable to
> > define new optional-to-understand frame types and send them without prior
> > negotiation.
> >
> > Now that we have this data, are we interested in pursuing the draft with
> > settings only, or perhaps reserving frame types but recommending caution
> in
> > their use?
>
> Ah! That's interesting, so that's the problem Yves and me have been
> working on yesterday where we found frame types 0xF7 sent by a Beta
> version of Chrome and rejected by haproxy! At least now we have an
> explanation! And I have a bug to fix now.
>
> But quite frankly that's exactly the expected outcome of a spec written
> in directive way instead of normative. I mean, instead of indicating
> state transitions it says what an agent must do. It's impossible for
> such a long text to remain consistent along the whole document and you
> end up with some conflicting rules. Here in the traces we've collected
> yesterday, we've found a frame type 0xF7 sent in half-closed(remote)
> state. And the spec says :
>
>    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 (Section 5.4.2) of
>       type STREAM_CLOSED.
>
> So by this rule, the 0xF7 I saw was not permitted.
>
> Further down it says:
>
>    In the absence of more specific guidance elsewhere in this document,
>    implementations SHOULD treat the receipt of a frame that is not
>    expressly permitted in the description of a state as a connection
>    error (Section 5.4.1) of type PROTOCOL_ERROR.  Note that PRIORITY can
>    be sent and received in any stream state.  Frames of unknown types
>    are ignored.
>
> And it's just in the middle of a paragraph in 5.5 that I can see :
>
>    Implementations MUST discard frames that have unknown or unsupported
>    types.
>
> With that said, for the cases I'm responsible of, the fixes are easy,
> and I'm even fine with tagging them as major bugs so that the fixes
> flow down into distros. Clearly, we try to fight protocol ossification
> but by writing specs that look almost like code with very strict rules
> we encourage it by accident, and we must be extremely careful about
> this in the future.
>
> I also think that for future designs, indicating prominently in a
> spec that some type ranges are reserved for experimentation and
> some for extensions will already ring a bell to some developers.
>
> There's still a problem is with already deployed code, but H2 compatible
> components in field are still young and experiencing frequent updates,
> so users will easily apply fixes. Thus I think that it's probably not
> to late to continue to enforce using unknown frame types to send such
> signals from time to time is the best way to make sure they're updated.
>
> And, just like there have been flag days for IPv6 or DNS, we could have
> some H2 days once or twice a year during which browsers will send random
> protocol elements. Just making this public will encourage users to care
> about the correctness of their components and pressure their vendors to
> provide a compliant implementation.
>
> Just my two cents,
> Willy
>
>