Re: Standard for upgrading based on URL?

On Tue, Oct 12, 2021 at 4:40 PM Felipe Gasper <felipe@felipegasper.com>
wrote:

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

No, something like this wouldn't really work for what HTTP/2 is trying to
do in the first place. One of the biggest benefits of newer protocols like
HTTP/2 and HTTP/3 is better use of the network via connection reuse. That
means that switching protocols on a request-by-request basis doesn't really
work. As a client, once a suitable HTTP/2 or HTTP/3 connection is
available, incoming requests will go to that connection. If clients probed
the server with a new connection first, we'd negate all the benefits.

The in-band upgrade didn't give you this property either. (The in-band
upgrade is getting removed in http2bis because no one implemented it, so
I'm guessing you haven't tested this?) Even if it is initiated by something
URL-triggered, the end result is an HTTP/2 connection. So, suppose you hit
/new-endpoint and upgraded to HTTP/2. The client now has an HTTP/2
connection available, so when you go to hit /legacy-endpoint, it would
reuse that HTTP/2 connection rather than making a new one. Your HTTP/2
server continues to be responsible for /legacy-endpoint.

If porting the legacy endpoints to the new application server is difficult,
I think the best solution is for your HTTP/2 frontend to forward the legacy
endpoints to the old application server, while speaking HTTP/2 to the
client. This lets you apply the benefits of HTTP/2 across your entire
origin.

David