RE: On pipelining

Daniel Hellerstein wrote,
> Basically,  in the following scenario (from mike sabin)..
>
> Request1
> Request2
> Request3
>         Response1
>         Response2
>         Response3
>
> 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)

As I read it RFC 2616 is silent on this. I think that's as it
should be, because server-side client-specific state isn't
any part of the HTTP protocol. Again as I read it, a server
is allowed to process the requests it receives on a persistent 
connection in any order it chooses, including concurrently, so 
long as responses are returned in the same order as the 
corresponding requests were sent.

I don't think that strictly speaking the constaints in 9.1.2
apply, because they're supposed to be enforced by the user-
agent before request are sent rather than when they arrive at 
the server.

Cheers,


Miles (not Mike ;-)

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

Received on Friday, 21 January 2000 08:02:19 UTC