- From: Miles Sabin <msabin@cromwellmedia.co.uk>
- Date: Fri, 21 Jan 2000 16:00:26 -0000
- To: Daniel Hellerstein <DANIELH@mailbox.econ.ag.gov>, http-wg@cuckoo.hpl.hp.com
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