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

PROPOSAL: i99 Pipelining Problems

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 25 Mar 2008 22:26:55 +1100
Message-Id: <89867851-941B-4A2D-8C07-9A90411EFBBA@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>

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  
>> - 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 Tuesday, 25 March 2008 11:27:40 UTC

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