Re: Time to refresh HTTP/2?

Hi Martin,

On Mon, Aug 31, 2020 at 10:10:20AM +1000, Martin Thomson wrote:
> On Fri, Aug 28, 2020, at 23:00, Mark Nottingham wrote:
> > What about priorities?
> 
> I would be opposed to publishing a new version with a replacement priorities
> scheme before that scheme were proven.  It might be OK to publish a version
> with text with the priority scheme removed, with a note about it not being
> interoperable in practice or some such.

I agree that we need to continue to document the protocol that is met
in field so if priorities are in use they must remain documented, possibly
just with a note about them being historic and progressively abandonned
for interoperability reasons.

> On Sat, Aug 29, 2020, at 00:54, Cory Benfield wrote:
> > I'm +1 on this as well. I'd like to see the extensions rolled in,
> > along with GREASE. I'm a bit more nervous about the priority changes
> > given how relatively young they are.
> 
> Cory agrees with me, so I'm probably right....  As for GREASE, I'm reluctant
> to include new design work, but it might be small enough to meet the cut.

Maybe it could be a sentence in each section suggesting what could safely
be greased (or conversely what's known for being unsafe to grease due to
some past mistakes or early deployments).

> > Am 28.08.2020 um 13:27 schrieb Willy Tarreau:
> > +1 as well. Wouldn't it be an opportunity to also reference (or even merge)
> > the extensions such as RFC8441 which adds the ":protocol" pseudo-header ?
>  
> I tend to think that 8441 wouldn't make the cut; it's discrete in the same
> way that the ORIGIN or ALTSVC frames are.

I was thinking about this because the initial rules for :method/:authority/
:path/etc were pretty strict and resulted in some hard-coded checks in the
code I wrote, to the point that every time I thought "I really need to work
on relaxing this to cover 8441", the number of changes in sight made me lazy.
I'm fine with just a sentence indicating that these ones may be altered by
extensions, with a link to 8441 as an example of such.

> On Fri, Aug 28, 2020, at 21:52, Julian Reschke wrote:
> > And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...
> 
> 8740 might make the cut.

Yes that would be nice indeed.

> Just to add to the list:
> 
> * midders (or multiple trailers or whatever they are) are something I'm still uncertain about
> * a re-design that included better 0-RTT design is probably off the table
> * removing h2c is very tempting, with similar rationale to PRIORITY

I believe that initially we all thought that nobody would dare sending an
H2 preface to an H1 server and that we'd all go the H1 upgrade way. But
in the end, many implementations (both clients and servers) now support
H2 in clear text by simply detecting the preface, and I'm not sure how
many have implemented the h2c mode with the upgrade. At least I haven't.

Another thing I would like to see is unifying the frame flags. We know
that all similar flags have the same value for any frame where defined
but they are still declared as frame-specific, which is a pain to stick
to. I'd rather see a central list of supported flags and indicate what
frame supports what flag.

We'd also need to figure a way to better define how to deal with errors
because I remember seeing contradictions at a number of places depending
on the state-specific or frame-specific rules. It might be easier to
collect some feedback and suggestions now that there are many
implementations. I tend to think that sticking to what to do on frame
receipt might make things clearer.

Cheers,
Willy

Received on Monday, 31 August 2020 05:30:36 UTC