Re: HTTP/2 GREASE, Results, and Implications

Hi Tom,

first, thanks for reloading this.

On Fri, Nov 15, 2019 at 07:10:31AM -0800, Tom Bergan wrote:
> 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.
(...)
> 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 we do this, we should really change the wording to never use "other than"
and instead explicitly mention the list of frame types that are not permitted
in each state.

> 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.

I'm fine with this point. However I do have a real concern regarding
deployed code now based on the fact that the way this ambiguity is present
can have caused solid roots to be set inside some software. For example
when trying to address the issue in haproxy, I noticed that we've used
bit fields of permitted frame types to more easily match what's allowed
or not. When working around them I figured that changing tests constructed
this way to think in terms of exclusion instead wasn't always as riskfree
as I initially imagined, and if we relax certain rules we need to be sure
that (almost) all implementations will accept to revisit their code and
take such risks in maintenance versions to allow smooth updates of deployed
components, or we really risk the same type of fragmentation that we've
known with HTTP/1.1.

I have been wondering if we could classify frame types into 2 or 3
categories :
  - those permitted on stream 0
  - those permitted on an open stream
  - those permitted after END_STREAM or on an idle stream

I even suspect that the last one should be cut into two. The question
was whether we could have imagined simplifying the handling of extra
frame types by saying that only certain ranges of frame types will be
permitted in certain situations which would allow to better handle
extensions in the future, but after checking in my code I'm not
convinced anymore that this could really help. Thus I think that your
point about any frame type adding a new arc on the state graph should
only be used through negotiation is probably the only option.

But I still do have some concerns about our ability to extend the
protocol even without this. What if a new frame expects an ACK for
example ? Probably this one will also require an extension. And for
those plugged on the stream without the ability to really participate
(typically a firewall or a wireshark dissector), maybe declaring that
the ACK flag is always the same bit 0 and that any frame type holding
an ACK should be ignored regardless of the context could make sense.

Just a few thoughts.

Willy

Received on Friday, 15 November 2019 15:59:24 UTC