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

RE: About draft-nottingham-http-pipeline-01.txt

From: Brian Pane <B.Pane@F5.com>
Date: Fri, 25 Mar 2011 20:13:46 +0000
To: HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <0E7D714EB2A2FD448E8AC47AF485EED76059E4C7@SEAEMBX01.olympus.F5Net.com>
Willy Tarreau wrote:
> It's not clear to me when reading it. Maybe I missed an important point,
> but the only relevant item I've found was about the fact that adding
> the header is forbidden for proxies.

Speaking of which, what's the rationale for prohibiting proxies from adding the Assoc-Req header?

There's a use case where it seems reasonable to allow proxies to add the header: a reverse proxy in front of the web server (e.g., a load balancer or cache) might be quite capable of handling pipelined requests, but it might have to serialize requests to the origin server if the latter isn't known to support pipelining properly.  This arguably is a very useful setup, as it enables pipelining between the client and the reverse proxy (usually the high-RTT part of the trip), just not between the reverse proxy and the origin server (usually the low-RTT part of the trip).

Some additional thoughts on http://tools.ietf.org/html/draft-nottingham-http-pipeline-01 (from my perspective as somebody who's developed web servers and reverse proxies; I'd love to hear some input from the browser implementers too) ...

The use of the HTTP Link header for pipeline hinting is a double-edged sword.  The response header is often the easiest and least expensive place to add something to an existing web application.  The one downside I see is that response headers on a lot of websites are getting close to 1 MTU in size already, so adding Link headers on every response is not necessarily ideal.  Sending the Link headers on the first response per session (or, for the sake of efficient implementability, the first response per connection) might be a good balance, however.

The "/.well-known/pipeline" URI is straightforward to implement, but my concern is that it doesn't provide an answer fast enough in the following scenario:

- Dynamic content is served from www.example.com.
- Static content is served from a CDN, let's call it static.example.org.
- A client requests a page from www.example.com and receives an HTML document containing lots of links to static.example.org.
- The client then has to request static.example.org/.well-known/pipeline/ before it can tell whether static.example.com supports pipelining on all its resources.

In contrast, if the Link header in the www.example.com response indicates that static.example.org supports pipelined requests for all its resources, the client doesn't need to incur a round-trip delay to static.example.org to query /.well-known/pipeline/ before it can begin pipelining its requests.

The "quick" link relation type might lead to a problem in practice; how would one apply it to the <link> tag?
I don't think
    <link rel="quick" rel="stylesheet" type="text/css" href="http://static.example.org/style.css">
is valid; and even if it is, it's unclear whether client implementations would still recognize it as a stylesheet link.

Finally, I think there's value in enabling some sort of wildcard hint mechanism, perhaps in the form of a simple prefix match.  For example, given:
    Link: <http://www.example.org/i/>; REL=quick
the client could expect http://www.example.org/i/logo.png to be quick, but not http://www.example.org/login.html

Received on Friday, 25 March 2011 20:14:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:37 GMT