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