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

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

From: Patrick McManus <pmcmanus@mozilla.com>
Date: Wed, 15 Aug 2012 13:48:18 -0400
Message-ID: <1345052898.1116.36.camel@ds9>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Phillip Hallam-Baker <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
sorry - too much shorthand. This is for http:// urls of course..
https:// can just use npn on the A address.

race A and SRV queries.. make best practice to bundle SRV answers as
additional information in responses to A queries. Best experience
returns an A bundled with SRV. But if you get an A without a bundled SRV
then go ahead and use it immediately for HTTP/1 and allow a
upgrade/alternate-protocol to do the bootstrapping that less ideal way.

So its just an optimization.

On Wed, 2012-08-15 at 10:19 -0700, 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?
> 
> 
> http://code.google.com/p/chromium/issues/detail?id=22423#c9 has some
> of our thoughts on SRV in Chromium.
> 
> 
> 
> On Wed, Aug 15, 2012 at 6:00 AM, Patrick McManus
> <pmcmanus@mozilla.com> wrote:
>         On Tue, 2012-08-14 at 12:24 -0400, Phillip Hallam-Baker wrote:
>         
>         > If we take architecture seriously, the primary signaling
>         mechanism for
>         > HTTP/2.0 should be some form of statement in a DNS record to
>         tell the
>         > client 'I do HTTP 2.0'. We might also have some sort of
>         upgrade
>         > mechanism for use when the DNS records are blocked but that
>         should be
>         > a fallback.
>         
>         
>         This is my current thinking as well though I'm not tied to
>         it.. srv in
>         the base case (with the possibility of dnssec) and something
>         like
>         upgrade/alternate-protocol over HTTP/1 as a slower fallback.
>         
>         
>         
>         
> 
> 
Received on Wednesday, 15 August 2012 17:48:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 August 2012 17:48:52 GMT