Re: pipelined client/server behaviour

Adrian Chadd wrote:
> > Without changing the standard -- here's a proposed enhancement:
> > 
> >     "Connection: pipeline" may be included in a response to indicate
> >     that the agent generating the response (i.e. origin server or
> >     proxy) correctly handles pipelined requests on this connection.
> 
> I seem to recall reading an old mailing list post from a while ago where
> someone noted various implementations treated Connection: <anything not
> keepalive> as an implicit Connection: closed.

Fortunately, in this case, that does no great harm.  It's just a
performance loss for the broken implementation.

> >     Both origin servers and proxies may generate this, to indicate
> >     their support.
> > 
> >     Conservative clients and proxies may refrain from sending
> >     pipelined requests until this has been seen in a previous
> >     response.  For example, a client may generate one request on a new
> >     connection, and upon seeing this header, send more pipelined
> >     requests immediately.
> > 
> >     Being a "Connection" token, it will be stripped by intermediate
> >     proxies.  (Right...?)
> > 
> >     (Additional enhancements to pipelining, if any, may be indicated by
> >     a "Pipeline" header.  For example if response multiplexing or
> >     reordering were to be added, support would be indicated by
> >     appropriate value of this header).
> > 
> > Just a little thought which might make pipelining more deployable.
> 
> I thought about this a couple of days ago. You'd want to cover:
> 
> * out of order replies;

Yes.  (Indeed, I have already deployed an application which uses a
protocol very like HTTP but with out of order replies.)

> * non-pipelinable replies (eg streaming media) being a small 4xx or
>   5xx reply which is interpreted as a "No, don't do this via
>   pipelining; resubmit on its own connection please" so the
>   User-Agent doesn't have to wait for the end of the reply chain to
>   discover it hasnt' received a reply for a specific request (And
>   this gets worse if the last reply allows the connection to be
>   persistent and unfortunately the User-Agent expects a reply that
>   isn't coming.)

Streaming media (and streaming Javascript!) origin servers can signal
that already with "Connection: close".  The client is informed immediately
that it must resend later requests on another connection, and that
it's safe to repeat them because they won't be processed on this
connection.

> * I can see more than one situation where a pipeline request chain
>   of A, B and C does look to the User-Agent like a non-idempotent
>   sequence but does have some session or database expectation of
>   request order. If you treat the requests as potentially concurrent
>   requests to handle then things could get subtly confused.  If you
>   treat pipelining as purely a method to dodge request queue RTT and
>   have the server just do it right (ie, don't try to handle them
>   concurrently; handle them one at a time and pass off to the same
>   server) then pipelining behaviour suddenly looks like
>   non-pipelining behaviour.

When an application on the client side submits requests A, B and C,
_usually_ the client-side HTTP implementation has the option to
use multiple connections for those requests.  So they might be
processed in parallel anyway, without pipelining.

So an application really should not submit requests concurrently to
it's HTTP client implementatiom, without waiting for the intermediate
responses, unless parallel processing is ok.

Not doing that is usually a layering violation.

The other problem with non-idempotent requests is what to do if an
intermediate response is large and/or slow.  It's not possible to
repeat the non-idempotent requests which have been transmitted later.

I think the sensible rule is: only pipeline GETs.

-- Jamie

Received on Monday, 2 April 2007 12:32:59 UTC