Subject: RE: HTTP/3 Preface (PRI method)

From: Mike Bishop <[email-masked]>
Date: Tue, 6 Jul 2021 18:46:31 +0000

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 <[email-masked]> On Behalf Of ben=[email-masked]
Sent: Tuesday, June 29, 2021 3:47 PM
To: Matt Joras <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>
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=[email-masked]> 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

---

From: Roberto Peon <[email-masked]>
Date: Wed, 7 Jul 2021 18:50:52 +0000

Sure, but it is sad that we describe it that way-- would be nicer to state the requirements we need from the underlying transport and then say that QUIC is the only one that first those requirements at the moment...

-=R

On 7/6/21, 11:47 AM, "QUIC on behalf of Mike Bishop" <[email-masked] on behalf of [email-masked]> wrote:

---

From: "Piers O'Hanlon" <[email-masked]>
Date: Thu, 8 Jul 2021 09:38:39 +0000

Hi Ben,

It is also being proposed (and implemented by a number of organisations including Apple see: https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md) that the ALPN (and IP address(es)) may be obtained via the new proposed “HTTPS”  DNS resource record request:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https

Using this approach one can in principle pre-empt a “preface”, though clients would need to handle a potential discrepancy.

Best,

Piers O'Hanlon

> On 29 Jun 2021, at 20:10, ben=[email-masked] 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).
> 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.
>
> 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: [email-masked]
Date: Thu, 08 Jul 2021 12:33:07 +0200

I understand. It would be only useful when having HTTP/3 on TCP without 
SSL/TLS. I should read more to find out if that is even possible, but if 
it is, I think you need a preface. HTTP/3 over unsecured TCP would not 
be useful except for debugging/test purposes, so there is no need for 
adding preface to the spec, unless this feature will be covered too.

Piers O'Hanlon schreef op 2021-07-08 11:38:

> Hi Ben,
> 
> It is also being proposed (and implemented by a number of organisations 
> including Apple see: 
> https://github.com/MikeBishop/dns-alt-svc/blob/master/svcb-implementations.md) 
> that the ALPN (and IP address(es)) may be obtained via the new proposed 
> "HTTPS"  DNS resource record request:
> Using this approach one can in principle pre-empt a "preface", though 
> clients would need to handle a potential discrepancy.
> 
> Best,
> 
> Piers O'Hanlon
> 
>> 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).
>> <PATH> [VERSION] \n
>> If an endpoint is directly accessed (without some negotiation), it 
>> will find out the version directly by reading the first line.
>> 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?
>> in HTTP/3 too: PRI * HTTP/3.0
>>