- From: Phillip Hallam-Baker <hallam@gmail.com>
- Date: Wed, 15 Aug 2012 15:12:38 -0400
- To: Eliot Lear <lear@cisco.com>
- Cc: "William Chan (陈智昌)" <willchan@chromium.org>, Patrick McManus <pmcmanus@mozilla.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
It is not necessarily even a separate query. DNS has these things called 'additional records'. When you do an A-record lookup you typically get back a lot more than the A-record. You can also fire off the A-record and SRV record queries in parallel and then wait for both to arrive. This is what is almost always done for IPv6. Another approach is soft caching. DNS records have a set TTL of course and that has to be respected as far as the semantics of DNS go. But a client is entirely in their rights to use stale DNS data to inform optimizations. Roughly 80% of my Web browsing involves a small set of sites I visit every day. An even larger fraction are sites I visit every week. It is really not a problem to do a combi A/SRV lookup the first time and then remember how the site was configured for future reference. Then when you make the next request you choose the strategy most likely to be optimal based on past behavior. On Wed, Aug 15, 2012 at 1:40 PM, Eliot Lear <lear@cisco.com> wrote: > > On 8/15/12 7:19 PM, William Chan (陈智昌) wrote: > > Can you elaborate how SRV would work here from a client perspective? Do you > propose making the client block on the SRV lookup? Or are you proposing > doing this out of band and switching to HTTP/2.0 if we discover support? > > > Block is the wrong word. You're already doing A-Record queries. Adding > another record in the question only adds latency if you must serially query. > Also, I myself am not convinced that SRV records are sufficient to the task. > For instance, what happens if there is a port # in the URL? How do you > identify the version #? > > Paul Hoffman did some work on a draft that sort-of looked at this problem. > I'm going to guess that he stopped short because of potential downgrade > attacks. > > Eliot -- Website: http://hallambaker.com/
Received on Wednesday, 15 August 2012 19:13:07 UTC