W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2021

Re: Standard for upgrading based on URL?

From: Felipe Gasper <felipe@felipegasper.com>
Date: Tue, 12 Oct 2021 19:59:02 -0400
Cc: Nick Harper <ietf@nharper.org>, Ben Schwartz <bemasc@google.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <DFD6BD24-4C93-4F33-AACB-90DF19938332@felipegasper.com>
To: David Benjamin <davidben@chromium.org>


> On Oct 12, 2021, at 4:58 PM, David Benjamin <davidben@chromium.org> wrote:
> 
> 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.

That makes all the sense in the world. Thank you for explaining.

cheers,
-Felipe Gasper
Received on Tuesday, 12 October 2021 23:58:00 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 12 October 2021 23:58:01 UTC