[web-devel] Sending a Response before the Request has been entirely consumed?

[Jeremy Shaw]

Hello,

Is it valid for a server to start sending an HTTP Response before the
Request has been entirely consumed? Or to put it differently, is there any
case where it would be valid for the Response message-body to be streaming
the value from the Request message-body?

Doing that seems like it would, in general, not be a good idea. For
example, if you started sending a 200 OK response, and then you encountered
a parse error in the Request message body, there is no way to go back and
change to an error status code.

One slight exception seems to be the use of 100  (Continue), section 8.2.3,

http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

but even there, you are just looking at the Request headers, not trying to
stream from the Request message body to the Response message body.

In this section:

http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6

It says,

"After receiving and interpreting a request message, a server responds with
an HTTP response message."

Which could be interpreted to mean that the entire request message must be
received and interpreted before the response can be sent. But, that could
be reading too much into it. I'd rather see something like:

"The server MUST read the entire request message before sending a response."

Any thoughts? Is there any definitive statement? Are there any real world
examples where you would want to stream the request message body into the
response? For example, a service where you can PUT/POST a document, and it
gets transformed on the fly and returned in the response?

At this point I am inclined to design the server such that you must read
the entire request message before you can begin sending the response. But,
if that is a mistake, I'd love to hear about it now ;)

- jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130917/73a6a82e/attachment.htm>