- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 23 Oct 2012 13:50:46 +1100
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 23/10/2012, at 1:33 PM, William Chan (陈智昌) <willchan@chromium.org> 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 > http://www.ietf.org/mail-archive/web/tls/current/msg05593.html? 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 http://www.mnot.net/
Received on Tuesday, 23 October 2012 02:51:04 UTC