On 2013-09-18 01:54, Jeremy Shaw wrote: [--snip--]
I'm still thinking that sending a response body that depends on the request body before the whole request body has been received is asking for trouble.
A couple of use cases: Server-Sent Events (aka. EventSource in HTML5). In that case you never full receive the (empty) request body, since your goal is to not close the connection at all. And generalizing slightly: You want this if the server can decide, based on the currently received *prefix* of the full request body, that it can send some *prefix* of the response body already. (It might even make sense even if the server later has to "cancel" some part of the previous response by writing a "cancel instruction" later in the response. For example, if latency in getting the first bit of data is more important than complete accuracy.) This would generally make most sense in streaming scenarios, but I could imagine this the general prefix-based consideration might apply to e.g. synchronization algorithms based on comparing hash-trees for instance. Of course, unless you can guarantee that the response will below the networking buffer size, your client must be nonblocking/multi-threaded :). Regards,