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

[Jeremy Shaw]

So, section 8.2.2 says:

~~~~
8.2.2 Monitoring Connections for Error Status Messages

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.
~~~~

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.

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?

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.

So, we can assume the client *might* read the Response before it sends all
the Request, but we should definitely not rely on it?

- jeremy




On Tue, Sep 17, 2013 at 2:30 PM, Jeremy Bowers <jerf at jerf.org> wrote:

> On 09/17/2013 03:08 PM, Jeremy Shaw wrote:
>
>> Hello,
>>
>> 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?
>>
>>  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.
>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130917/56f45ace/attachment.htm>