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

[Bardur Arantsson]

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,