Subject: HTTP/3 Preface (PRI method)

From: [email-masked]
Date: Tue, 29 Jun 2021 21:10:47 +0200

Hello all,

When reading about QUIC, it comes to me as a better alternative of TCP, 
build upon UDP.
In this case, servers that run on TCP could easily also run on UDP/QUIC; 
think about DNS, SMTP, FTP.

Now there is also a new version of HTTP. HTTP/3. This version will be 
transfered over QUIC by default.
However, as I mentioned above, it could be possible to have "TCP 
protocols" that use QUIC too.
That makes me think about also transfering some old HTTP versions, for 
example HTTP/0.9 (I came across a library that transfered HTTP/0.9 over 
QUIC).
But also HTTP/1.0, HTTP/1.1 and HTTP/2 are possible.

All older HTTP versions send the following request line: <METHOD> <PATH> 
[VERSION] \n
If an endpoint is directly accessed (without some negotiation), it will 
find out the version directly by reading the first line.
For 0.9 the version will be absent. For 2.0 this will be a preface with 
a PRI method and * as path.

When I think about running a HTTP server, I think about this:

TCP (80) or TCP/SSL (443):
  - HTTP/0.9
  - HTTP/1.0
  - HTTP/1.1
  - HTTP/2.0
  - HTTP/3.0 (I think this is possible too)

UDP/QUIC:
  - HTTP/0.9 (HTTP/0.9 but over QUIC)
  - HTTP/1.0 (HTTP/1.0 but over QUIC)
  - HTTP/1.1 (HTTP/1.1 but over QUIC)
  - HTTP/2.0 (HTTP/2.0 but over QUIC)
  - HTTP/3.0 (Default)

However, if I listen for all versions on my HTTP-QUIC server, how am I 
supposed to know that it is HTTP/3? Does HTTP/3 has a preface? And if 
not, why not?
I think the preface of HTTP/2 is great and I think it would be great in 
HTTP/3 too: PRI * HTTP/3.0

I would like to see a preface added to HTTP/3.0. It is only 18 extra 
bytes at the beginning of the request. It could be ignored by some 
servers if they want, but for servers that want to have backwards 
compatibility it would be a great feature. (Luckily HTTP/3 is not a 
released standard yet.)

Ben

---

From: Matt Joras <[email-masked]>
Date: Tue, 29 Jun 2021 12:30:54 -0700

Hi Ben,

This issue in general, if I'm understanding you correctly, is solved via
the ALPN[1]. I.e., as part of the TLS handshake the server will be able to
know which application is being used. For example, "h2" corresponds to
HTTP/2 and "h3" corresponds to HTTP/3. Also note that there are no
standardized mappings of HTTP over QUIC except for the currently-pending
HTTP/3 specification. Future versions of HTTP over QUIC would also be
distinguished via ALPN, presumably.

Best,
Matt Joras

[1] https://datatracker.ietf.org/doc/html/rfc7301

---

From: Nick Harper <[email-masked]>
Date: Tue, 29 Jun 2021 12:40:44 -0700

I agree with Matt that the signalling of the application protocol is best
handled via ALPN and no in-band (e.g. in a STREAM frame) signalling is
needed.

There's also a more fundamental problem with having a preface in HTTP/3.
Unlike a TCP connection where there is a single stream of data (and a
preface can be placed at the beginning of the connection), a QUIC
connection has multiple independent streams of data. There's no sensible
place to place a preface like what HTTP/2 has on a QUIC connection.

---

From: [email-masked]
Date: Tue, 29 Jun 2021 21:47:02 +0200

I understand. When connecting through QUIC using TLS, it will tell me 
that HTTP/3 is used. However, I see HTTP/3 as protocol that isn't just 
allowed on QUIC, but also still on TCP, because QUIC is a 
TCP-alternative. So, we look to three cases:
  - QUIC: use the ALPN code
  - TCP/SSL: use ALPN code
  - Plain TCP: What to do then? HTTP/3 directly starts with binary.

It seems to me that HTTP should be developed like it is just an 
protocol, not specific made for QUIC or TCP. So in that case, there 
should be placed a preface somewhere.

Matt Joras schreef op 2021-06-29 21:30:

> Hi Ben,
> 
> This issue in general, if I'm understanding you correctly, is solved 
> via the ALPN[1]. I.e., as part of the TLS handshake the server will be 
> able to know which application is being used. For example, "h2" 
> corresponds to HTTP/2 and "h3" corresponds to HTTP/3. Also note that 
> there are no standardized mappings of HTTP over QUIC except for the 
> currently-pending HTTP/3 specification. Future versions of HTTP over 
> QUIC would also be distinguished via ALPN, presumably.
> 
> Best,
> Matt Joras
>

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 29 Jun 2021 13:05:40 -0700

HTTP/3 is defined to be HTTP over QUIC so HTTP/3 over TCP doesn't really
make sense.