- From: 陈智昌 <willchan@chromium.org>
- Date: Tue, 23 Oct 2012 21:25:06 -0700
- To: Patrick McManus <mcmanus@ducksong.com>
- Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, Oct 23, 2012 at 11:54 AM, Patrick McManus <mcmanus@ducksong.com> wrote: > > > On Mon, Oct 22, 2012 at 10:33 PM, William Chan (陈智昌) <willchan@chromium.org> > wrote: >> >> >> Just to be clear, SRV records also have the disadvantage of not >> upgrading the first interaction, unless you block on the response, > > > also being clear - in cases where SRV wins the race there is an advantage to > be had without blocking. A high quality implementation can bundle the srv > response with the A as an additional record.. even if that isn't what is > happening today, supporting this mechanism provides a path for servers to > opt themselves into it without blocking on it. And of course sometimes name > resolution happens considerably before connect happens so there still might > be an opportunity to collect both the a* and the srv before going to connect > without blocking on it even if the SRV considerably lags the A. So I think > this is an important optimization. Ah, I totally forgot that DNS prefetches might significantly mitigate the penalty of an srv lookup. Good point, thanks. > > but +1 on not building in a mandatory delay inducer like blocking on srv, or > an upgrade with an empty payload. >
Received on Wednesday, 24 October 2012 04:25:33 UTC