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

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

From: Adrien W. de Croy <adrien@qbik.com>
Date: Wed, 15 Aug 2012 23:40:52 +0000
To: "Patrick McManus" <pmcmanus@mozilla.com>, William Chan (陈智昌) <willchan@chromium.org>
Cc: "Phillip Hallam-Baker" <hallam@gmail.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <em9cf630fe-388b-4364-816c-76aa33e63cda@bombed>

------ Original Message ------
From: "Patrick McManus" <pmcmanus@mozilla.com>
>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.
>
problem with this, is that now you need to wait for your DNS server 
vendor to give you a new DNS server you can use to do this.

I think making an additional requirement to deploy a new DNS server 
will be a bit of a show-stopper.

I think it would be easier to just request both, and wait for both 
responses.  That's if we decide SRV is the way to go.

But like Elliot, I'm not convinced SRV is right for this problem.  It 
provides a port number and a weight.  There may be some use for the 
weight, but the port number is problematic, since we're talking about 
using 80/443.  Which port number is used?  What if the URL contains a 
port number etc?

Maybe it would be simpler to just do an optimistic A record lookup.  
E.g. prepend some well-known token, such as 

_http2.www.example.org.

if you get a record back, you know it supports http 2.  If you don't 
you just look up www.example.org.  these 2 requests can be fired off in 
parallel.

That makes it a lot easier to deploy on the server and client side as 
well, since the domain operator only needs to publish additional A 
records, and client doesn't need to do SRV lookups.

I'm pretty sure most people will hate that idea though.

Adrien

>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 23:41:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 15 August 2012 23:41:31 GMT