RE: On pipelining
Miles Sabin (msabin@cromwellmedia.co.uk)
Fri, 21 Jan 2000 16:00:26 -0000
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/