Subject: Removals from HTTP/2

From: "Martin Thomson" <[email-masked]>
Date: Thu, 22 Apr 2021 14:49:30 +1000

When we last met on this topic, we discussed the removal of Upgrade and PRIORITY from HTTP/2.

The general sense was removal of Upgrade was easy.  People seemed generally OK with taking PRIORITY out in a compatible way (with a more complete excision reserved in case we found reasons to use a new ALPN identifier).

In both cases, the sense was that people wanted to see specific text and have time to review the changes.  Pull requests have been available for a while, though they weren't advertised here:

Upgrade: https://github.com/httpwg/http2-spec/pull/820
PRIORITY: https://github.com/httpwg/http2-spec/pull/795

Please review these and comment if you think that this is the wrong direction to take.  The usual quibbles and suggestions are also most welcome (preferably as comments on the changes directly).  It would be good to have a revision of the spec with some of these more fundamental changes ahead of our next interim.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 22 Apr 2021 08:01:17 +0200

Hi Martin,

On Thu, Apr 22, 2021 at 02:49:30PM +1000, Martin Thomson wrote:
> In both cases, the sense was that people wanted to see specific text and have
> time to review the changes.  Pull requests have been available for a while,
> though they weren't advertised here:
> 

Both look good to me. The second one will have to drop its first chunk once
the first one is merged (since it describes priority across Upgrade).

Given the deprecation of the PRIORITY frames and the explicit mention of
the lack of a better alternative, should we add a specific warning that
these frames must not be reused for experimental purposes as they may still
be consumed by servers ?

Willy

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 22 Apr 2021 16:30:58 +1000

> the first one is merged (since it describes priority across Upgrade).

Yeah, fixing that should be simple enough.

> these frames must not be reused for experimental purposes as they may still

We're pointing to the new priority draft, which uses a different frame type.  Do you think it worthwhile saying "frames with this type cannot be reassigned different semantics?"  Technically you can negotiate different format or semantics for any frame; in practice, this is probably a terrible idea and so we'd look to discourage that.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 22 Apr 2021 08:39:06 +0200

On Thu, Apr 22, 2021 at 04:30:58PM +1000, Martin Thomson wrote:
> We're pointing to the new priority draft, which uses a different frame type.
> Do you think it worthwhile saying "frames with this type cannot be reassigned
> different semantics?"  Technically you can negotiate different format or
> semantics for any frame; in practice, this is probably a terrible idea and so
> we'd look to discourage that.

I think we should. Since the document explicitly suggests that "some
might or some might not use them", "removing support is probably worse
than keeping it", "each side ought to do what it thinks is best", I'm
pretty sure it will give a signal to implementations that they can start
to deviate a little bit from a deprecated standard if they figure it helps
in their situation. And we've seen in the past that dependencies on closed
streams and such things could have horrible effects. For this reason I'd
rather see one sentence like:

   "Although deprecated, PRIORITY frames, if sent, MUST strictly conform
    to their definition in RFC7540 and may in no way be used to experiment
    with alternate mechanisms."

It's cheap, and there are plenty of frame types available to play with.

Willy