Re: PROPOSAL: i99 Pipelining Problems

Hmm.

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