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: 'Connection reset by peer' when replying before the end of POST data Date: Tue, 28 Feb 2012 23:15:46 +0100 Message-ID: <20120228221546.GC16985@candra> 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 1330467364 29215 80.91.229.3 (28 Feb 2012 22:16:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 28 Feb 2012 22:16:04 +0000 (UTC) To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Tue Feb 28 23:15:59 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 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:327 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 1S2VKs-00012Y-SO for gclrrg-rainbows-talk@m.gmane.org; Tue, 28 Feb 2012 23:15:55 +0100 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 82788263031; Tue, 28 Feb 2012 22:15:53 +0000 (UTC) Received: from mail.poivron.org (poivron.org [91.194.60.101]) by rubyforge.org (Postfix) with ESMTP id 298DF263027 for ; Tue, 28 Feb 2012 22:15:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) with ESMTPSA id 1CBCE1085BF Hi! Short introduction: I am working on a simple "one-click" file sharing web application specific focus on protecting users' privacy=A0[1]. Thanks to Rainbows! it can work with big uploads without any request buffering which is simply marvelous! :) 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! Here is a minimal test case: --- 8< --- config.ru --------------------------------------------------- class InterruptTest def call(env) # HTTP 1.1 standard (and curl) needs this /\A100-continue\z/i =3D~ env['HTTP_EXPECT'] and return [ 100, {}, [] ] error =3D "Request entity too large!\n" env['rack.input'].read 1000 Rainbows.sleep 1 [ 403, { 'Content-Type' =3D> 'text/plain' }, [ error ] ] end end run InterruptTest.new --- >8 ----------------------------------------------------------------- --- 8< --- rainbows.conf ----------------------------------------------- Rainbows! do use :ThreadSpawn rewindable_input false client_max_body_size nil end --- >8 ----------------------------------------------------------------- I am starting Rainbows! with the following command-line: $ rainbows -E none -p 8081 -c rainbows.conf rackup.ru And then, when asking curl (the `test` file is 7636 bytes long): $ curl -v -F "file=3D@test;type=3Dtext/plain" http://localhost:8081 * About to connect() to localhost port 8081 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 8081 (#0) > POST / HTTP/1.1 > User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 > OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 > Host: localhost:8081 > Accept: */* > Content-Length: 7829 > Expect: 100-continue > Content-Type: multipart/form-data; > boundary=3D----------------------------cd790f73307f > = < HTTP/1.1 100 Continue < HTTP/1.1 403 Forbidden < Date: Tue, 28 Feb 2012 21:20:15 GMT < Status: 403 Forbidden < Connection: close < Content-Type: text/plain < = Request entity too large! * Recv failure: Connection reset by peer * Closing connection #0 curl: (56) Recv failure: Connection reset by peer This "connection reset by peer" is annoying as it will result in Apache stating "Bad gateway", or Firefox displaying "The connection was reset". I believe Rainbows::MaxBody having the same issue, but I am not sure. Also looking at the code, it looks like Rainbows::MaxBody trust the Content-Length header and do not mesure the actual amount of bytes received if the header is present. I believe Content-Length can be faked by malicious clients, so it might be better to use limit_input! for every connections. 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. I see that Nginx has options related to SO_LINGER and that Apache also mention "Lingering Close" when discussing how to close connections. But I don't really know where to poke on Rainbows! to play with these kinds of options. Anyway, this issue looks closeloy like the one described in section 8 of . Thanks again for any help solving this. :) [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. :) [2] 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