John Fieber <jfieber at adobe.com> wrote:> I have a bug where some Rack middleware that determines certain
> PUT/POST error responses without needing to read the request body. On
> Linux, this causes a TCP reset when Unicorn closes the socket with
> unread data in the input buffer. The reset preempts the delivery
> written but still buffered response, so client receives a simple RST
> and no response. If I inject some read-buffer draining code just
> before the close, the problem goes away.
>
> The RST behavior is obviously not desired, but my question is what
> level of the stack is responsible for making sure it doesn''t
happen?
> It strikes me that Unicorn is in the best position to do it
> efficiently and reliably, but anything higher up can also do it.
Hi John,
You have to use the read buffer draining code in your app or middleware.
The Unicorn::TeeInput class doesn''t read off the socket until it needs
to. This is because Rack requires the input stream to be rewindable,
and the input stream being rewindable means it must be buffered to a
temporary file which could potentially fill up the disk (especially with
chunked input that doesn''t declare a Content-Length).
So Unicorn gives apps/middleware control to cut off uploading clients in
this case.
--
Eric Wong