Re: comments on draft-mbelshe-httpbis-spdy-00

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 <> 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


Received on Wednesday, 15 August 2012 19:13:07 UTC