From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS33070 50.56.128.0/17 X-Spam-Status: No, score=0.5 required=3.0 tests=FROM_LOCAL_NOVOWEL, MSGID_FROM_MTA_HEADER,TVD_RCVD_IP,UNPARSEABLE_RELAY shortcircuit=no autolearn=unavailable version=3.3.2 Path: news.gmane.org!not-for-mail From: Lunar Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: 'Connection reset by peer' when replying before the end of POST data Date: Wed, 29 Feb 2012 08:22:34 +0100 Message-ID: <20120229072234.GB9007@candra> References: <20120228221546.GC16985@candra> <20120228233919.GA10168@dcvr.yhbt.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1330500170 4208 80.91.229.3 (29 Feb 2012 07:22:50 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Feb 2012 07:22:50 +0000 (UTC) To: Rainbows! list Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Wed Feb 29 08:22:49 2012 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Content-Disposition: inline In-Reply-To: <20120228233919.GA10168-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:329 Archived-At: Received: from 50-56-192-79.static.cloud-ips.com ([50.56.192.79] helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S2ds8-0006eO-F2 for gclrrg-rainbows-talk@m.gmane.org; Wed, 29 Feb 2012 08:22:48 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id D2F5E26303B; Wed, 29 Feb 2012 07:22:46 +0000 (UTC) Received: from mail.poivron.org (poivron.org [91.194.60.101]) by rubyforge.org (Postfix) with ESMTP id 32703263033 for ; Wed, 29 Feb 2012 07:22:38 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) with ESMTPSA id EBA6C10040B8 Hi Eric, Thanks for your quick answer! Eric Wong wrote: > Lunar 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 =3D env['rack.input'] > buf =3D "" # 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=A0[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]=A0 > 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]=A0You can have a look at > > , 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