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. On Tue, Jun 29, 2021 at 12:31 PM Matt Joras <[email protected]> wrote: > 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 >> >>
