From: Lunar <lunar-L8VBg9NU5dbk1uMJSBkQmQ@public.gmane.org>
To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org
Subject: 'Connection reset by peer' when replying before the end of POST data
Date: Tue, 28 Feb 2012 23:15:46 +0100 [thread overview]
Message-ID: <20120228221546.GC16985@candra> (raw)
Hi!
Short introduction: I am working on a simple "one-click" file
sharing web application specific focus on protecting users' privacy [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 =~ env['HTTP_EXPECT'] and return [ 100, {}, [] ]
error = "Request entity too large!\n"
env['rack.input'].read 1000
Rainbows.sleep 1
[ 403, { 'Content-Type' => '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=@test;type=text/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=----------------------------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
<http://ftp.ics.uci.edu/pub/ietf/http/draft-ietf-http-connection-00.txt>.
Thanks again for any help solving this. :)
[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. :)
[2] <https://httpd.apache.org/docs/2.2/misc/perf-tuning.html>
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 reply other threads:[~2012-02-28 22:15 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-28 22:15 Lunar [this message]
2012-02-28 23:39 ` 'Connection reset by peer' when replying before the end of POST data Eric Wong
[not found] ` <20120228233919.GA10168-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org>
2012-02-29 7:22 ` Lunar
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: http://yhbt.net/rainbows/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120228221546.GC16985@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
http://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).