In response to my last post, Mark pointed out that .NET's HTTPClient supports pipelining. Heikki said that Mozilla put in support for this but it isn't turned on normally because so few servers support it. Furthermore, Heikki reports that tests showed only a 7% performance increase when Mozilla uses pipelining. The Mozilla FAQ is a good start for information on this though it doesn't have the data.

The application I had in mind (Chandler) does more synchronization than browsing over HTTP/WebDAV. For example, if the user decides to work offline, and while offline moves a bunch of resources from one collection to another, then goes online again, Chandler would have to issue one MOVE request for each moved resource. With pipelining, Chandler could theoretically fire each request off and wait to start seeing the responses come back in order over the same connection. The only thing limiting throughput is the bandwidth and MOVE requests and responses don't take up that much. Without pipelining, Chandler has to wait for each response before sending the next request. Now this work is limited by latency, multiplied by the number of resources being moved.

Still, I don't consider this proof that pipelining would be useful. It would be great to see more data one of these days -- assuming, of course, that there really is a performance problem in the first place.