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

Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 1 Mar 2012 18:26:42 +0100
To: Brian Pane <brianp@brianp.net>
Cc: ietf-http-wg@w3.org
Message-ID: <20120301172642.GH9937@1wt.eu>
On Thu, Mar 01, 2012 at 08:39:40AM -0800, Brian Pane wrote:
> On Wed, Feb 29, 2012 at 11:18 PM, Willy Tarreau <w@1wt.eu> wrote:
> > On Wed, Feb 29, 2012 at 03:16:22PM -0800, Mike Belshe wrote:
> >> The problem with upgrade is that it costs a round trip of latency.
> >
> > Not for the first request since the server responds to this request.
> > And since in HTTP you need the first request anyway to fetch the page
> > to discover the objects you'll have to request next, it's not an issue
> > for the first request of the keep-alive connection.
> I think you're making the assumption that the page and the objects it
> requires are served from the same FQDN, right?  In my experience, it's
> common for a page served from example.com to reference static objects
> served from example.org.  Thinking about the various reasons people
> serve resources from different hostnames today,

Oh I fairly agree, but right now if your browser opens a connection to
a different domain for any of the reasons below, it still doesn't pipeline
before the first round trip which ensures that HTTP/1.1 is supported.

> - Domain sharding: not needed if HTTP/2.0 allows parallel requests on
> one TCP conn
> - Cookie-free domains: not needed if HTTP/2.0 provides header compression
> - Resources served by third parties: still needed under HTTP/2.0
> - Resources served by a CDN: still needed under HTTP/2.0 (even though
> parallelization of requests will reduce the number of round trips
> needed to fetch n resources, there's still value in reducing the
> length of each round trip; and people will continue to use CDNs for
> scalable/elastic traffic handling)
> Thus I think it's essential for HTTP/2.0 to handle the following use
> case efficiently:
> - The client has a list of n resources it knows it needs
> - Those n resources are all available under the same scheme:host:port
> - The resources are independent of each other and can be fetched in any order

I too agree and don't think that anything proposed till now was against
these principles.

Received on Thursday, 1 March 2012 17:27:08 UTC

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