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

Re: #385: HTTP2 Upgrade / Negotiation

From: Willy Tarreau <w@1wt.eu>
Date: Wed, 24 Oct 2012 09:10:46 +0200
To: Mark Nottingham <mnot@mnot.net>
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <20121024071046.GE7331@1wt.eu>
On Wed, Oct 24, 2012 at 05:52:52PM +1100, Mark Nottingham wrote:
> 
> On 24/10/2012, at 5:48 PM, Willy Tarreau <w@1wt.eu> wrote:
> 
> > On Wed, Oct 24, 2012 at 06:21:47PM +1300, Amos Jeffries wrote:
> >> For the other types of middleware the DNS is irrelevant as you say. So 
> >> where is the benefit come in from doing it when middleware is involved? 
> >> there is none. Yet the interceptors will cause problems. A very 
> >> unbalanced situation leaning towards breakage.
> >> 
> >> I'm +0 on the DNS mechanism. Looks good, but only for a small segment of 
> >> the market.
> > 
> > I'd go further, the problem with DNS is that by design it's used to
> > provide information for one record which corresponds to a host name.
> > In my opinion it's totally unsuited for use with HTTP the way it's
> > used today because I see no way it would cover the following cases :
> > 
> >  - multiple IP addresses advertised at different locations for the
> >    same record, possibly talking different protocol versions due to
> >    a progressive deployment. Eg :
> > 
> > 	$ host -t a google.com
> > 	google.com has address 74.125.230.197
> > 	google.com has address 74.125.230.196
> > 	google.com has address 74.125.230.201
> > 	google.com has address 74.125.230.200
> > 	google.com has address 74.125.230.192
> > 	google.com has address 74.125.230.199
> > 	google.com has address 74.125.230.195
> > 	google.com has address 74.125.230.193
> > 	google.com has address 74.125.230.198
> > 	google.com has address 74.125.230.206
> > 	google.com has address 74.125.230.194
> > 
> >  - anycast routing : the same name and IP address exist on two continents,
> >    but they don't necessarily speak the same version. Some CDNs right now
> >    use anycast, it would be better if we don't tell them "switch all your
> >    nodes at once".
> > 
> >  - react to quick changes : you're installing your shiny new gateway
> >    supposed to talk http/2. You advertise it in DNS. Then you realize
> >    it crashes. Oops, rollover to previous 1.1 gateway, but the bad was
> >    already made, the world knows you're on the new one and caches this
> >    for some time. Site remains randomly accessible for the time users
> >    cache the record ;
> > 
> >  - multiple service versions at the same IP address as is often encountered
> >    on internal networks. For example, you have dynamic on :80 and :443 in
> >    HTTP/1 and static on :8080 and :8443 using HTTP/2. And note that in
> >    developer environments, it's very common to have 100+ ports bound on
> >    a same host with different applications being developped. I wouldn't be
> >    one of these users if my browser randomly used either version to access
> >    the application I'm developing depending on DNS records...
> > 
> > Seriously, I think that using negociation for the standard scheme is the
> > only way to make something compatible with what exists. Having a new scheme
> > is fine to say 2.0 only but as someone (I don't remember whom) said a
> > few months ago, proxies will have no choice but to obey and they won't all
> > be 2.0 ready for some (long) time.
> 
> Willy, 
> 
> A fair number of folks has said they want this, and no one is saying that it's mandatory.

Not being mandatory still means that browsers will have to decide what to
do based on this record at one point, with lists of exceptions.

> AFAICT most of your problems can be boiled down to:
> 
> 1) Different servers may back up one DNS record - in which case, they don't have to use SRV
> 
> 2) Clients assuming HTTP/2 may fail - in which case, we need to design things so they can recognise this and fall back to 1.1 seamlessly.

While this seems to be a prerequisite to me, it does not sound like the
solution to everything : failing fast is what we all hope for, but we
know well that there are environments where the failure will cause delays
etc... (you're well aware of the issues faced by pipelining for example).
So similarly we'll have some boxes drop packets or simply not forward data
when they discover junk after the request headers.

DNS records are just for global view of how the server is presented to the
net, but it does not take into account the whole path to the clients.

I'd suggest that the zero-roundtrip upgrade is made only on TLS using the
NPN extension that already works well with SPDY. The advantage is that it
says what protocol can be spoken on top of a connection and does not rely
on external components unaware of the path.

And for clear text we'd keep the good old HTTP upgrade which should be
optimal for the most common usages (GET/HEAD first) and require that
other methods would be handled as 1.1 during the first round trip. I
don't see this as a terrible tradeoff.

Willy
Received on Wednesday, 24 October 2012 07:11:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 07:11:24 GMT