Re: HTTP/3 Preface (PRI method)

[Ryan Hamilton <[e-mail]>]

HTTP/3 is defined to be HTTP over QUIC so HTTP/3 over TCP doesn't really
make sense.

On Tue, Jun 29, 2021 at 12:47 PM <ben=[e-mail]> wrote:

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