PROPOSAL: i99 Pipelining Problems

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