Re: #385: HTTP2 Upgrade / Negotiation

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.

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?

Regards,



--
Mark Nottingham   http://www.mnot.net/

Received on Wednesday, 24 October 2012 06:53:15 UTC