W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: #385: HTTP2 Upgrade / Negotiation

From: 陈智昌 <willchan@chromium.org>
Date: Tue, 23 Oct 2012 21:25:06 -0700
Message-ID: <CAA4WUYj7X3=PotU_ZFrZVhgi+tzhucoCcVZ5tgsD=JX6Kf4MFA@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 24 October 2012 04:25:35 GMT