W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2008

Re: PROPOSAL: i99 Pipelining Problems

From: Julian Reschke <julian.reschke@gmx.de>
Date: Fri, 04 Apr 2008 15:00:22 +0200
Message-ID: <47F62666.5000106@gmx.de>
To: Mark Nottingham <mnot@mnot.net>
CC: HTTP Working Group <ietf-http-wg@w3.org>


Any volunteers for providing spec-ready text?

BR, Julian

Mark Nottingham wrote:
> Formalising the proposal discussed before;
>> Here's a summary of the problems people have mentioned so far;
>>> - Handle the first m of n requests in order, then skip to request n 
>>> (IIRC I saw this on IIS/5)
>>> - Handle the first request in a packet, ignore the rest, then process 
>>> the first in the next, and so on. I have seen this problem in WebSeal 
>>> 5 (IBM) where it was fixed, and then recently broke in WebSeal 6, and 
>>> is apparently fixed again recently. The problem is particularly 
>>> visible for HTTPS in Opera 9, but is not limited to HTTPS.
>>> - Handle one or more requests, then stall
>>> - Handle a request, then stall when the next arrives.
>>> - Not quite pipelining: Server sending Content-Length of original 
>>> content, then apply Content-Encoding without removing or updating the 
>>> Content-Length header. I have seen this happen with PHP using global 
>>> compression when the script sets the Content-Length header.
>>> - Not knowing how many requests this connection will be able to 
>>> serve. The default in httpd is 100 requests per connection, but 
>>> svn.collab.net tuned it down to 10 - which caused all sort of fun 
>>> when testing ra_serf against Subversion's own repository.  I 
>>> eventually got them to up it back to the default.  serf tries to 
>>> figure out the limit heuristically (i.e. write as much as possible, 
>>> then count how many responses we got before the connection closed - 
>>> that'll be the limit going forward).
>>> - Lost responses are, sadly, real.  Later versions of httpd 2.0.x 
>>> re-introduced a lingering close bug where it won't wait for the last 
>>> packet to be written; this is fixed in 2.2.x, but have to be 
>>> accounted for.
>> My proposal: Hand this to the editors and instruct them to include a 
>> *short* (i.e., not necessarily this level of detail) note stating that 
>> pipelining is difficult to implement for clients (both UAs and 
>> intermediaries), giving some of the underlying causes (e.g., bad 
>> server implementations, difficult runtime choices) and leave it at that.
> -- 
> Mark Nottingham     http://www.mnot.net/
Received on Friday, 4 April 2008 13:01:04 UTC

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