about summary refs log tree commit homepage
path: root/lib/rainbows/max_body.rb
DateCommit message (Collapse)
2011-05-10max_body: documentation updates
It can't be used as middleware for fully-buffering concurrency models.
2011-05-10configurator: move validation logic over
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 updates
speling ficks and less confusing #initialize documentation
2011-05-03s/max_bytes/client_max_body_size/ for consistency
Too confusing otherwise...
2011-02-04rename XAcceptEpoll to XEpoll
It's too long especially since XEpollThreadPool is planned :>
2011-01-24initial XAcceptEpoll concurrency model
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 epoll
It's almost just like Coolio
2011-01-06eliminate G constant and just use the Rainbows! module
Code organization is hard :<
2010-12-27initial cool.io support
Cool.io is the new name for Rev. We'll continue to support Rev until Cool.io breaks backwards compatibility. Rev may not be supported if Cool.io is.
2010-11-19max_body: do not enable for RevThread* models
Those already use CapInput, just like the rest of the evented Rainbows! world.
2010-11-16reimplement client_max_body_size handlers
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 files
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 + kgio
We get basic internal API changes from Unicorn, code simplifications coming next.
2010-07-10doc: avoid documenting internals on RDoc website
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 users
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 message
2010-05-03add client_max_body_size config directive
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.