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
[1] https://datatracker.ietf.org/doc/html/rfc7301
On Tue, Jun 29, 2021 at 12:11 PM <[email protected]> wrote:
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
