Re: #385: HTTP2 Upgrade / Negotiation

On 24/10/2012 4:44 p.m., Mark Nottingham wrote:
> On 24/10/2012, at 12:23 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
>
>>> For browsers, upgrading on the first connection is obviously going to be
>>> critical. The DNS option seems like the best approach for the most general
>>> case, despite the various flaws in that approach.
>> *except* for all those cases where middleware exists. In which case DNS hinting will be the cause of problems, not the solution.
> How so?
>
> For  accelerators / "reverse" proxies, the party in control of the middleware is in control of the DNS.
>
> For configured proxies, the client is aware of the middleware and can figure out and remember its capabilities, via the upgrade mechanism.
>
> It's only for unconfigured / "transparent" / intercepting proxies that this might be a problem. If the protocol is designed to fail fast in their presence, this too should be manageable -- there might be some latency on first request in these networks, at worst. Bonus points for putting the blame squarely where it lies somehow...

Yes they are the major hassle and they are not going away until that 
blocker problem of browsers not supporting TLS to proxies is resolved. 
Rolling out DNS record dependency, even if only as a first attempted 
connection in their presence is a guaranteed fail for that DNS mechanism.

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.

Amos

Received on Wednesday, 24 October 2012 05:22:21 UTC