- From: Felipe Gasper <felipe@felipegasper.com>
- Date: Tue, 12 Oct 2021 16:38:21 -0400
- To: Nick Harper <ietf@nharper.org>
- Cc: Ben Schwartz <bemasc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
> On Oct 12, 2021, at 4:15 PM, Nick Harper <ietf@nharper.org> wrote: > > Upgrading a connection from HTTP/1 to HTTP/3 isn't possible since they use different underlying transports (TCP vs QUIC). Oops! Sorry, I meant upgrading to H2. > What would be the use case for starting a TLS connection using HTTP/1 and then later upgrading to HTTP/2, instead of always using HTTP/2 on the connection? The in-band upgrade mechanism provided for h2c only exists so that a client without prior knowledge can use h2c; a similar mechanism isn't needed for h2 (over TLS) because the signal that HTTP/2 is supported is carried in ALPN. We have an application server that only serves H1 right now. We’d like to be able to add new endpoints using H2 without having to rewrite the entire thing. So: https://ourapp.com/legacy-endpoint <--- We’d like not to rewrite this (for now). https://ourapp.com/new-endpoint <--- We’d like to write this in H2. The in-band upgrade mechanism for h2c trivially allows this since the URL is part of the client’s first sent line, but it doesn’t seem like the ALPN-based negotiation can allow that … or is there some way for the client to send the URL during the TLS handshake? Thank you! -FG
Received on Tuesday, 12 October 2021 20:37:22 UTC