From: Lunar <lunar-L8VBg9NU5dbk1uMJSBkQmQ@public.gmane.org>
To: Rainbows! list <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org>
Subject: Re: 'Connection reset by peer' when replying before the end of POST data
Date: Wed, 29 Feb 2012 08:22:34 +0100 [thread overview]
Message-ID: <20120229072234.GB9007@candra> (raw)
In-Reply-To: <20120228233919.GA10168-yBiyF41qdooeIZ0/mPfg9Q@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
next prev parent reply other threads:[~2012-02-29 7:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 22:15 'Connection reset by peer' when replying before the end of POST data Lunar
2012-02-28 23:39 ` Eric Wong
[not found] ` <20120228233919.GA10168-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-02-29 7:22 ` Lunar [this message]
2012-02-29 17:23 ` Eric Wong
[not found] ` <20120229172315.GA26630-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-02-29 20:57 ` Lunar
2012-02-29 21:36 ` Eric Wong
[not found] ` <20120229213601.GA7116-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-03-02 16:03 ` Lunar
2012-03-02 16:29 ` Lunar
2012-03-02 21:05 ` Eric Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://yhbt.net/rainbows/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120229072234.GB9007@candra \
--to=lunar-l8vbg9nu5dbk1umjsbkqmq@public.gmane.org \
--cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://yhbt.net/rainbows.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).