'Connection reset by peer' when replying before the end of POST data
lunar at anargeek.net
Wed Feb 29 07:22:34 UTC 2012
Thanks for your quick answer!
Eric Wong wrote:
> Lunar <lunar at anargeek.net> wrote:
> > I am currently trying to implement a limit on the maximum uploaded file
> > size, not unlike what is already done by Rainbows::MaxBody.
> > Unfortunately, it looks like answering a request while the client is in
> > the middle of posting data is not supported that well by Rainbows!
> You can also drain the socket to avoid connection resets:
> input = env['rack.input']
> buf = "" # reuse buf to reduce GC pressure
> while input.read(1024, buf)
> # ignore buf, keep reading until nil
I thought about it, but I would rather not do that. Coquelicot is meant
as a small, self-contained application that can also be run at home
behind broadband connections with small bandwidth or quota. If users set
a file limit of 5 MiB, I would rather not drain the whole 700 MiB before
denying the request.
> > In any cases, I would very much like to solve this issue, but I feel a
> > little bit lost on where to start.
> > My assumption was that other webservers were doing it right, otherwise
> > no one would ever see a 413 Request Entity Too Large message in a
> > browser.
> They probably drain the socket or wait a bit before closing the
> connection. Rack doesn't give developers much control over how the
> socket is managed.
Quoting the "HTTP Connection Management" document  which I mentioned
previously: "Servers must therefore close each half of the connection
After digging some more at Nginx, it looks like Nginx is doing exactly
that. I also looked at Apache and the code responsible for half-closing
both side of the connection is very readable. Function is called
`ap_lingering_close()` in server/connection.c.
It looks like there is no way to call shutdown(2) in Ruby 1.8.7, but
from the documentation, Ruby 1.9.3 has IO#close_read and IO#close_write
method that will call shutdown(2) for each half of a socket.
I don't have Ruby 1.9.3 right now, but I can try to produce a test case
later demonstrating the differences between calling `@io.close` and
In any case, I think it would worth to try to add such call sequences in
Rainbows! and see if it helps. If you can't give it a shot yourself,
could you point me to the relevant part of the code?
> Also, neither Matz Ruby 1.8 nor 1.9 can do lingering close as IO#close
> still holds onto the GVL (blocking all clients).
> I tried to make close(2) release the GVL for 1.9.3, but it doesn't
> interact well if another thread was operating on that IO object.
I am not that versed in Ruby internal, but I fail to see how this could
be related to first closing the clients write side of the connection.
There should be a window between IO#close_write and IO#close in which in
GVL does not matter, does it?
> >  You can have a look at
> > <https://git.codecoop.org/projects/coquelicot>, but there is not
> > that much to see yet. The code using Rainbows! is not yet in a
> > releasable state, but progress is steady, so expect some news
> > later. :)
> Cool (especially that you host your own), I don't see an obvious way to
> clone your repo and look at it, though :x
I will keep the list in touch when interesting meat is available. In the
meantime, you should be able to `git://git.codecoop.org/coquelicot.git`
(maybe in a few hours, it looks the public access got lost at some
More information about the rainbows-talk