Subject: Time to refresh HTTP/2?

From: "Martin Thomson" <[email-masked]>
Date: Fri, 28 Aug 2020 17:15:06 +1000

All this tiresome talk about terminology got me thinking about the value of action over words.

So, I present to you a proposed update to RFC 7540:

  https://datatracker.ietf.org/doc/html/draft-thomson-httpbis-http2bis-00

This only does:

* removes unnecessarily divisive terminology
* rolls up errata

Obviously, there is a long and slippery slope of things that we might do from this point.  However, I think that it would be good if we could just publish a minimal update without getting embroiled in difficult and time-consuming design questions.

The diff is mostly just stuff that xml2rfc does differently five years on:

  https://tools.ietf.org/rfcdiff?url1=https://ietf.org/rfc/rfc7540.txt&url2=https://www.ietf.org/id/draft-thomson-httpbis-http2bis-00.txt

Or you can peruse the individual changes I made:

  https://github.com/http2/http2-spec/compare/master...martinthomson:main

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Aug 2020 12:59:03 +0200

>    https://github.com/http2/http2-spec/compare/master...martinthomson:main

+1

Actually, I was going to suggest that as well, but mainly to align
HTTP/2 with the new core specs - it would be good to say how the cleanup
affects the references from HTTP/2.

Best regards, Julian

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 28 Aug 2020 13:27:08 +0200

> affects the references from HTTP/2.

+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 ?

Willy

---

From: Julian Reschke <[email-masked]>
Date: Fri, 28 Aug 2020 13:52:24 +0200

> the extensions such as RFC8441 which adds the ":protocol" pseudo-header ?

And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...

Best regards, Julian

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 28 Aug 2020 23:47:27 +1200

>   https://github.com/http2/http2-spec/compare/master...martinthomson:main

+1.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 28 Aug 2020 23:00:05 +1000

Hi Martin,

Just my personal .02 - this seems reasonable, as do the suggestions for folding in other subsequent changes.

What about priorities?

Cheers,

> On 28 Aug 2020, at 5:15 pm, Martin Thomson <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 28 Aug 2020 14:27:10 +0100

Hey Martin,

I had a similar thought about a document update, motivated by the recent
discussion on GREASING.

I support this work and would like us to roll GREASING text in so that we
have consistency across H2 and H3.

Cheers
Lucas

---

From: Cory Benfield <[email-masked]>
Date: Fri, 28 Aug 2020 15:54:02 +0100

> Obviously, there is a long and slippery slope of things that we might do from this point.  However, I think that it would be good if we could just publish a minimal update without getting embroiled…

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 31 Aug 2020 10:10:20 +1000

It seems like everyone wants their swing at this.

To be perfectly frank, I wasn't planning on addressing any of these.  It's a long and slippery slope.

But I will start a list and we can discuss where to draw the line. 

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

Here's some historical info that seems relevant.  The following text appears in the draft, commented out:

> Note that stream dependencies have not yet been validated in practice.  The theory
> might be fairly sound, but there are no implementations currently sending these.  If it
> turns out that they are not useful, or actively harmful, implementations will be requested
> to avoid creating stream dependencies.

While this might be true, I don't want a reprise.

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

> affects the references from HTTP/2.

I definitely had that in mind.  My plan is to do that once the -core drafts leave the working group (so that there is no further risk of reshuffling.

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

> And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...

8740 might make the cut.

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

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 31 Aug 2020 07:30:17 +0200

Hi Martin,

On Mon, Aug 31, 2020 at 10:10:20AM +1000, Martin Thomson wrote:
> 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.

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

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

> > And it probably should include RFC 8740 ("Using TLS 1.3 with HTTP/2")...

Yes that would be nice indeed.

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

---

From: Cory Benfield <[email-masked]>
Date: Mon, 31 Aug 2020 07:47:16 +0100

> On 31 Aug 2020, at 06:30, Willy Tarreau <[email-masked]> wrote:
> 
> Hi Martin,
> 

Yeah, I’m with Willy: I think we need _some_ wording here to address RFC7540 § 8.1.2.1:

>   Endpoints MUST NOT
>   generate pseudo-header fields other than those defined in this
>   document.

This MUST NOT feels stronger than it is, due to fact that § 5.5 gives explicit permission to change these MUST NOT statements. Suitable text would probably just indicate that endpoints MUST NOT generate non-7540 pseudo-header fields except by negotiation with the peer (e.g. via SETTINGS), but that HTTP/2 does support extending in this form.

>> * removing h2c is very tempting, with similar rationale to PRIORITY

Of this list the only thing I’m really tempted to add is removing h2c, and I don’t know whether that’s just because removing stuff is great. So I don’t think I’d lose any sleep if we left all of these changes out, at least for now.

---

From: Julian Reschke <[email-masked]>
Date: Mon, 31 Aug 2020 10:50:14 +0200

Am 31.08.2020 um 02:10 schrieb Martin Thomson:
> ...

...and then there's the related question whether the updated HTTP core
documents would then reference rfc7540bis - but that would only be
realistic if it could be done at around the same time.

Best regards, Julian