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:

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