<div dir="ltr">So, section 8.2.2 says:<div><br></div><div>~~~~<br><div>8.2.2 Monitoring Connections for Error Status Messages</div><div><br></div><div>An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection.</div>
<div>~~~~</div><div><br></div><div>It's a bit ambiguous what it means by error status -- but let's assume it means a Response with a 4xx or 5xx series error code.</div><div><br></div><div>How does this interact with HTTP persistent connections. If the server sends a 4xx error code, there could still be other valid requests in the queue? If the request had a content-length header, then the client is going to close the connection on us, so there is nothing more for us to do. But if it was chunked, it sounds like we could drain any remaining data it sends and then process additional requests over the persistent connection?</div>
<div><br></div><div>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. For example, let's assume that the client is a simple, non-threaded client which attempts to send the entire request before reading the response at all. (After all, SHOULD and MAY are not the same as MUST). If the server tried to stream directly from the request body into the response body, that would likely result in a deadlock because the client would not be reading any of the response until it was done sending the entire request. And the server would not be reading more of the request because it would be blocked trying to send the response.</div>
<div><br></div><div>So, we can assume the client *might* read the Response before it sends all the Request, but we should definitely not rely on it?</div><div><br></div><div>- jeremy</div><div><br></div><div><br></div></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 17, 2013 at 2:30 PM, Jeremy Bowers <span dir="ltr"><<a href="mailto:jerf@jerf.org" target="_blank">jerf@jerf.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 09/17/2013 03:08 PM, Jeremy Shaw wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
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?<br>
<br>
</blockquote></div>
I don't know about valid from a "standards" point of view, but a valid use case, yes. For some reason or other, you are able to determine early that you do not care to answer this request, and you want to drop it or return an error as rapidly as possible. For instance, if a particular page is getting DOS'ed, part of your mitigation strategy might be to bail out of any request for that page as early as possible, or if it's because a particular page is being over-accessed you might want to return a static snapshot ASAP and get on with the next request. Or based on IPs, or whoknows what.<br>
<br>
I think you're right that returning a 200 before you've seen the entire header is probably never a good idea, but there are many 4xx and 5xx series responses you can make.<br>
</blockquote></div><br></div>