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 08:48:50 +0200
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: Mark Nottingham <mnot@mnot.net>, ietf-http-wg@w3.org
Message-ID: <20121024064850.GD7331@1wt.eu>
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.

Received on Wednesday, 24 October 2012 06:49:39 UTC

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