Re: #385: HTTP2 Upgrade / Negotiation

On 23/10/2012, at 1:33 PM, William Chan (陈智昌) <> wrote:

> Overall, sounds good. I've included some clarifications/questions below.


>> Who's willing to do some experimentation? Specifically, does anyone have access to the code that was used before (IIRC, people bought some ads and inserted some Java to probe the network)?
> Do you mean the Chromium HTTP upgrade experiment agl referred to in

No, IIRC there was also some broader experimentation using ads; I'll dig around a bit more. 

Of course, if Chrome (or any other browser) would be interested in running an experiment, we'd love to do that too -- provided we can have input into the design.

>> Does anyone object to us defining such a record (type TBD), as long as it's not the only way to get to HTTP/2 for HTTP URIs?
> I'm not sure if my previous emails were taken to indicate "interest"
> here. I forget what I said too :) As long as this is more of an
> optional optimization than anything, I guess I'm OK with it. I'm very
> much concerned about relying on it, due to experiments we have run
> with TXT records that show us noticeably higher failure rates in
> comparison to port 443, higher latency (we'd definitely have to race
> this), and extra DNS queries.

Yes, I think relying on it would be a mistake, for a variety of reasons.

>> 2) Using a response header to hint that HTTP/2 is available on another port.
>> This approach hasn't been talked about in detail yet, but it apparently (as some have noted) has the disadvantage of not upgrading the first interaction, and of requiring a separate cache (and caching model) for this information.
> Just to be clear, SRV records also have the disadvantage of not
> upgrading the first interaction, unless you block on the response,
> which Chromium definitely is not going to do unless the environment
> changes such that it doesn't kill performance.

I'll leave it to the DNS experts to debate the capabilities and merits here.

Mark Nottingham

Received on Tuesday, 23 October 2012 02:51:04 UTC