Things we'd like to remove or make mandatory in HTTP/2

[LPardue]

The latest revision to HTTP/2, RFC 9112, deprecated a few things that turned out to be duds but it didn't go as far as making any breaking changes.

What if we had infinite scope to change the wire image in a breaking way? What would you like to see removed altogether, changed, or newly added as a mandatory feature? Here's my starter list:

1. Improve stream concurrency control (e.g. MAX_STREAMS)
2. Remove server push
3. Remove RFC 7540 priorities (recommend RFC 9218?)
4. Restrict SETTINGS to once per connection at the start
5. Mandate extended CONNECT
6. Use QUIC variable-length integers (expand from 32-bit to 64-bit integers)
7. Grease every extension code point
8. Remove frame flags field - replace this with frame type instead (similar to QUIC and HTTP/3)
9. Remove CONTINUATION frames (larger frame sizes obviate them)
10. Mandate TLS; remove cleartext and upgrade (and hence avoid complications related to cleartext)
11. Remove prior knowledge and the preface stuff. (ALPN is enough to determine what a connection is being used for)
12. Tweak so that stream errors allow to elicit an error HTTP response rather than just a RST_STREAM

any comments or suggestions?

[kazuho]

Thank you for opening the issue. The list looks good, modulo the points below.

10. Mandate TLS; remove cleartext and upgrade (and hence avoid complications related to cleartext)
11. Remove prior knowledge and the preface stuff. (ALPN is enough to determine what a connection is being used for)

I agree that we do not need the complications (i.e., preface and upgrade), but I would very much prefer to retain the capability of using HTTP without encryption.

The rationale is that HTTP/2 is used not only over the network but also as an IPC protocol within a server through UNIX sockets or loopback interfaces. The protocol is also used in cleartext for intra-datacenter IPC calls (consider gRPC).

In such deployments, there is no need for encryption. And also, it is very hard to setup a server supporting TLS in such deployments (how do you obtain a certificate? You cannot use let's encrypt for this purpose).

Assuming that the intent is to revise HTTP/2, I would hope that this existing use-case would be missed. Hence the objection for "disabling" use of cleartext.

[LPardue]

Thanks for description of the use cases.

If we continued to support a clear text mode, I think it would require a preface so that we avoid ussues with misidentification of protocol. But maybe the TLS version can omit it.

[kazuho]

If we continued to support a clear text mode, I think it would require a preface so that we avoid ussues with misidentification of protocol. But maybe the TLS version can omit it.

That's true, though I would probably say that we do not need an explicit preface if we choose the correct frame encoding and number for the first frame (i.e., SETTINGS) being sent.

To give an example, assuming that we use a TLV format using quicints, the first bytes being sent on the wire would be either of "0x04", "0x4004", "0x80000004", "0xc000000000000004" (I'm using SETTINGS frame type of 0x04 as an example). None of the four variations yield to a valid HTTP/1.1 request or a HTTP/2 preface.

[Marcos323232]

Everything sounds good

[Acconut]

10. Mandate TLS; remove cleartext and upgrade (and hence avoid complications related to cleartext)
11. Remove prior knowledge and the preface stuff. (ALPN is enough to determine what a connection is being used for)

I recently encountered a use case for H2C. In Google Cloud Run, you can choose whether the TLS-terminating proxy communicates with the origin server via HTTP/1 or H2C. People actually want to control this because different request/response limits apply based on the HTTP version, e.g. request size. For such internal traffic H2C is useful.

[LPardue]

10. Mandate TLS; remove cleartext and upgrade (and hence avoid complications related to cleartext)
11. Remove prior knowledge and the preface stuff. (ALPN is enough to determine what a connection is being used for)

I recently encountered a use case for H2C. In Google Cloud Run, you can choose whether the TLS-terminating proxy communicates with the origin server via HTTP/1 or H2C. People actually want to control this because different request/response limits apply based on the HTTP version, e.g. request size. For such internal traffic H2C is useful.

This might be an argument to keep the notion of prior knowledge, albeit maybe with some tweaks compared to what is in https://www.rfc-editor.org/rfc/rfc9113.html#section-3.3