Re: Multiple responses from one request

In a previous episode Daniel Hellerstein said...
:: 
:: I suspect this is a no-no, but my reading of rfc2616 doesn't give me a
:: definitive answer;
:: 
:: The question:
::   Can an http 1.1 serverr "pipeline" multiple responses (over a
:: maintained connection)
::   to a single request;  without using a mulitpart content type (and
:: suitable dividers).
:: 

you're right.. a definite non-starter.. 1.4 makes it pretty clear that
there's a single response for every request..

consider in a a persistent scenario if 1+ responses where allowed for
each request, and the browser sent a second request to the server (it
is persistent..).. how does the browser know if response 2 is tied to
the first or second request? (and remember that the server may not
have even received the 2nd request even though it's entirely out of
the browser..).. it's a labelling issue.. it's one of the same reasons that
you can't return responses in a different order than you received the
requests, even if head of line blocking makes that inefficient.

-P

:: For example
:: a) client requests /pictures/anim5.cgi
:: b) the "anim5.cgi" script responds with 5 differerent images, say
::    with a second or two wait between images
:: c) This response is over the single connection 
:: 
:: Thus, the response would look something like;
:: 
:: http/1.1 200 Ok
:: Content-type: image/gif
:: Content-length: 251
:: 
:: (image1 info, that is 251 bytes long)
:: http/1.1 200 Ok
:: Content-type: image/gif
:: Content-length: 412
:: 
:: (image21 info, that is 412 bytes long)
:: ....
:: http/1.1 200 Ok
:: Content-type: image/gif
:: Content-length: 1311
:: 
:: (image5 info, that is 1311 bytes long)
:: 
:: Okay, this may be a stupid thing to do, given the way most browsers
:: will react
:: (i.e.; they won't replace images to form a server push animation)..
:: The point is that   I'm trying to decide if I should attempt to
:: detect, and then disallow, this sequence of events in a "customizable"
:: http/1.1 server I'm revamping.
:: 
:: Thanks
:: 
:: Daniel Hellerstein
:: http://www.srehttp.org
:: danielh@crosslink.net
:: 
:: 

Received on Thursday, 17 February 2000 10:25:11 UTC