Re: HTTP/2 GREASE, Results, and Implications

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

Received on Thursday, 31 October 2019 15:53:08 UTC