Re: HTTP/3 Preface (PRI method)

[Nick Harper <[e-mail]>]

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 <[e-mail]> 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 <ben=[e-mail]> 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
>>
>>