Subject: On pipelining

From: "Daniel Hellerstein" <[email-masked]>
Date: Fri, 21 Jan 2000 10:35:53 -0500

I'm redoing the persistent-connection/pipelining support in my web
server, and
the question came up of how to resolve pipelined requests. By resolve,
I mean
the act of the server using the request line (and headers, etc) to
determine which file to read, which script to run, etc ... the end
result being the creation of  a response to  send to the client.

Basically,  in the following scenario (from mike sabin)..

>  Request1
>  Request2
 > Request3
>         Response1
>           Response2
 >         Response3
>(although, clearly, if there are many requests we might expect 
>the request stream to partially overlap the response stream).

would "resolution of request2" await the completion of transmission
of response1? Or can these  3 requests be resolved simultaneously
(say, using
seperate threads); with first response1 sent, then 2, then 3.
That is, could a multi-threaded server create response2,  wait for
succesful transmission of  response1 (over the persistent connection),
and then transmit response2 (over this
same persistent connection)?

This is a problem if the resolution of request2 can depend on the
resolution of
request 1 (for example, when request1 causes some client-specific
state variable, that is  used in request2, to change)

The definition of idempotency (rfc2616  9.1.2)  suggests NO -- since
identical sequences should return the same result, which would
preclude
situations where the oddities of server load may dictate the  speed
with which
simultaneously resolved requests are processed.

Any strong opinions?

Daniel Hellerstein
[email-masked]
http://www.srehttp.org

---

From: "Scott Lawrence" <[email-masked]>
Date: Fri, 21 Jan 2000 10:59:41 -0500

> same persistent connection)?

If request1 is a GET, HEAD, TRACE, or OPTIONS, then I would say that
the server could legitimately assume that it had no side effects.
One could be more conservative and assume that any CGI (or CGI-like)
resource had side effects.  Having assumed that there were no side
effects it might be reasonable to overlap the processing, if you
have the buffer space to spare.

--
Scott Lawrence      Director of R & D        <[email-masked]>
Agranat Systems   Embedded Web Technology   http://www.agranat.com/