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

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

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 16 Aug 2012 09:47:28 -0400
Message-ID: <CAMm+LwibimC54MaXTEOxdS4AfFg+g-eWnTFHccg6+BPPWTwmdA@mail.gmail.com>
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>
The advantage of SRV is that is supports multiple hosted services
properly and eliminates the need for hacks like round robin DNS. It
also allows the port number to be specified separately for each
service. This allows two instances of a service on the same host which
is nice for testing.

If we are doing HTTP2 for performance we should support load balancing
and fault tolerance which is what SRV is for.

I suggest:

* If the URL specifies only the host name, use SRV lookup for _http2
first. If it is found, use http2.0

* if the URL specifies a port then use http/1.1

For testing purposes, it may be convenient to have a http2: scheme so
that the SRV thing can be separated from the protocol upgrade. In fact
that might be useful for signaling anyway..

On Thu, Aug 16, 2012 at 9:10 AM, Eliot Lear <lear@cisco.com> wrote:
> On 8/16/12 6:50 AM, William Chan (陈智昌) wrote:
> Can you clarify the reason to prefer srv over something like an
> Alternate-Protocol response header? I can see that Alternate-Protocol is
> suboptimal in that it requires waiting for a response first, but I have
> concerns about adding yet another DNS lookup. Chromium has already lowered
> our concurrent getaddrinfo() calls to 6 due to problems with home routers
> not being able to handle too many concurrent DNS queries. Adding more DNS
> lookups per hostname will further exacerbate the problem.
> And whatever mechanism is used has to work with the http: schema, which
> includes a port.
> Eliot

Website: http://hallambaker.com/
Received on Thursday, 16 August 2012 13:47:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:06 UTC