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

Re: #385: HTTP2 Upgrade / Negotiation

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 24 Oct 2012 17:52:52 +1100
Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <E6668847-2CA5-43C5-B8CC-C7C8AB06CFF1@mnot.net>
To: Willy Tarreau <w@1wt.eu>

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
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
> 	google.com has address
>  - 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.


A fair number of folks has said they want this, and no one is saying that it's mandatory.

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.

Make sense?


Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 24 October 2012 06:53:15 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC