RE: HTTP/3 Preface (PRI method)

[Mike Bishop <[e-mail]>]

Regardless of how you see HTTP/3, the RFC-to-be says this:

> HTTP/3 relies on QUIC version 1 as the underlying transport. The use of other QUIC transport versions with HTTP/3 MAY be defined by future specifications.

That is, there is no such thing as HTTP/3 over TLS over TCP.  Neither is there any such thing as HTTP/3 directly over TCP.  HTTP/3 assumes and relies on a multi-streamed transport underneath it; you can't just drop it on top of a single bytestream transport and expect it to work.  There would be far larger issues than the connection prefix.

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of ben=[e-mail]
Sent: Tuesday, June 29, 2021 3:47 PM
To: Matt Joras <[e-mail]>
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: HTTP/3 Preface (PRI method)

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 <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