I know that it is possible for a HTTP client to send the next request on a TCP connection even if it had not received the responses for its previous requests – this is called HTTP pipelining.
However, is it acceptable for a HTTP server to start transferring the response before the request had been received completely? Is there an RFC governing this behaviour?
E.g. imagine a service which receives some data via HTTP POST, does some transformation, and responds with the transformed data. If the transformation can be done in a streaming fashion, then the server can start producing the response body even if the request body is incomplete.
Best Answer
I'd be surprised if the standards explicitly described and blessed such an operation (because it's vanishingly rare you can be sure the partial request you have received contains enough information to start producing a response), but I expect it would work in most cases. Any data you send back in response almost certainly won't be read by the client until its finished sending the request, so it'll sit there in the read buffer until the client starts reading, at which point it'll think, "blimey that was fast!" and start chewing away merrily. It won't realise that the data was ALREADY INSIDE THE BUILDING...
I'm sure there's some odd-ball HTTP client implementation that does weird things with its sending loop such that if it finds the socket to be readable before its finished writing the request it freaks out, but the only way to find those is to try it out and see what breaks. That is, pretty much, how everything is done in HTTP-land anyway -- and how new standard behaviours get made (someone does something insane, which becomes popular enough that everyone else has to adapt, so the IETF WG says "fine, we'll make that behaviour the standard, then").