Hi,

I think pipelining can be a bit tricky down at the "ugly details" level...
:) For example, attempting to do POSTs over a pipelined connection is bad,
not only because you don't know when the POST executes at the far side, but
also because the "synchronous" 100 Continue just doesn't fit in with
pipelining.

On Tue, Dec 25, 2007 at 12:09:09PM +0300, Dmitry Kurochkin wrote:
> Also, at the moment all requests are sent immediately after connection is
> established. Instead we should wait for the first response, check that
> server accepts persistent connection and start pipelining only after
> that.

As I understand it, RFC 2616 allows you to send a pipelined request even if
you don't know whether the server supports it. IMHO it would be good to do
this, it will make e.g. spider-like programs (which contact lots of
servers) much faster. However, doing this requires you to resend all
pipelined requests in case it turns out the server doesn't support
pipelining.

This may seem a bit of extra work, but I think you will have to implement
the retry code anyway as the server may close the connection at any time
after a response.

Does anyone have a pointer to a document which describes all the tricky
details of pipelining?

Cheers,

  Richard

-- 
  __   _
  |_) /|  Richard Atterer     |  GnuPG key: 888354F7
  | \/¯|  http://atterer.net  |  08A9 7B7D 3D13 3EF2 3D25  D157 79E6 F6DC 8883 54F7
  ¯ '` ¯