Re: Standard for upgrading based on URL?

Hi Felipe,


On Tue, 12 Oct 2021, 21:40 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?
>


An alternative approach that is a proven effective strategy is to insert
something like a reverse proxy, load balancer or CDN in front of your
legacy servers. That way clients would talk H2 to all endpoints (as they
see it) but you would handle the dispatching of requests to different
servers with different capabilities yourself. That would let you stay fully
in control of migration without any hard to solve coordination challenges
with the actual clients.

Cheers
Lucas