summary refs log tree commit homepage
path: root/lib/rainbows/max_body.rb
AgeCommit message (Collapse)AuthorFilesLines
2011-05-10max_body: documentation updatesEric Wong1-1/+19
It can't be used as middleware for fully-buffering concurrency models.
2011-05-10configurator: move validation logic overEric Wong1-3/+8
There's actually no reason we can't have these methods in Rainbows::Configurator where it's easier to document nowadays.
2011-05-09max_body: rdoc updatesEric Wong1-6/+2
speling ficks and less confusing #initialize documentation
2011-05-03s/max_bytes/client_max_body_size/ for consistencyEric Wong1-2/+2
Too confusing otherwise...
2011-02-04rename XAcceptEpoll to XEpollEric Wong1-1/+1
It's too long especially since XEpollThreadPool is planned :>
2011-01-24initial XAcceptEpoll concurrency modelEric Wong1-1/+1
Edge-triggered epoll concurrency model with blocking accept() in a (hopefully) native thread. This is recommended over Epoll for Ruby 1.9 users as it can workaround accept()-scalability issues on multicore machines.
2011-01-21max_body: disable for epollEric Wong1-1/+2
It's almost just like Coolio
2011-01-06eliminate G constant and just use the Rainbows! moduleEric Wong1-2/+2
Code organization is hard :<
2010-12-27initial supportEric Wong1-1/+3 is the new name for Rev. We'll continue to support Rev until breaks backwards compatibility. Rev may not be supported if is.
2010-11-19max_body: do not enable for RevThread* modelsEric Wong1-1/+1
Those already use CapInput, just like the rest of the evented Rainbows! world.
2010-11-16reimplement client_max_body_size handlersEric Wong1-53/+50
This allows the client_max_body_size implementation to not rely on Unicorn::TeeInput internals, allowing it to be used with Unicorn::StreamInput (or any other (nearly) Rack::Lint-compatible input object).
2010-10-22unindent most filesEric Wong1-10/+8
This simplifies and disambiguates most constant resolution issues as well as lowering our identation level. Hopefully this makes code easier to understand.
2010-10-21unicorn 2.x updates + kgioEric Wong1-19/+19
We get basic internal API changes from Unicorn, code simplifications coming next.
2010-07-10doc: avoid documenting internals on RDoc websiteEric Wong1-0/+1
Since we suck at building websites, we just rely on RDoc as a website builder. And since Rainbows! is an application server (and not a programming library), our internal API should be of little interest to end users. Anybody interested in Rainbows! (or any other project) internals should be reading the source.
2010-05-03cleanup request size limiting for TeeInput usersEric Wong1-11/+4
WAvoid mucking with Unicorn::TeeInput, since other apps may depend on that class, so we subclass it as Rainbows::TeeInput and modify as necessary in worker processes. For Revactor, remove the special-cased Rainbows::Revactor::TeeInput class and instead emulate readpartial for Revactor sockets instead.
2010-05-03max_body: remove extraneous debug messageEric Wong1-1/+0
2010-05-03add client_max_body_size config directiveEric Wong1-0/+90
Since Rainbows! is supported when exposed directly to the Internet, administrators may want to limit the amount of data a user may upload in a single request body to prevent a denial-of-service via disk space exhaustion. This amount may be specified in bytes, the default limit being 1024*1024 bytes (1 megabyte). To override this default, a user may specify `client_max_body_size' in the Rainbows! block of their server config file: Rainbows! do client_max_body_size 10 * 1024 * 1024 end Clients that exceed the limit will get a "413 Request Entity Too Large" response if the request body is too large and the connection will close. For chunked requests, we have no choice but to interrupt during the client upload since we have no prior knowledge of the request body size.