Re: 'Connection reset by peer' when replying before the end of POST data

[Lunar <lunar-L8VBg9NU5dbk1uMJSBkQmQ@public.gmane.org>]

Hi Eric,

Thanks for your quick answer!

Eric Wong wrote:
> Lunar <lunar-L8VBg9NU5dbk1uMJSBkQmQ@public.gmane.org> 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
>       end

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 [1] which I mentioned
previously: "Servers must therefore close each half of the connection
independently."

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
`@io.close_write; @io.close`.

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?

[1] <http://ftp.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt>

> 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?

> > [1] 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
point).

Cheers,
-- 
Lunar
_______________________________________________
Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
http://rubyforge.org/mailman/listinfo/rainbows-talk
Do not quote signatures (like this one) or top post when replying