| Date | Commit message (Collapse) |
|---|
|
|
|
This should be logical, since we keep the connection alive
when writing in our writer threads.
|
|
|
|
|
|
|
|
It's not worth the trouble and testability since having
a single thread tends to bottleneck if there's a bad
client.
|
|
Idle threads are cheap enough and having responses
queued up with a single slow client on a large response
is bad.
|
|
This is based on an idea I originally had for Unicorn but never
implemented in Unicorn since the benefits were unproven and the
risks were too high.
|
|
It'll be useful later on for a variety of things!
|
|
Mostly internal cleanups and small improvements.
The only backwards incompatible change was the addition of the
"client_max_body_size" parameter to limit upload sizes to
prevent DoS. This defaults to one megabyte (same as nginx), so
any apps relying on the limit-less behavior of previous will
have to configure this in the Unicorn/Rainbows! config file:
Rainbows! do
# nil for unlimited, or any number in bytes
client_max_body_size nil
end
The ThreadSpawn and ThreadPool models are now optimized for serving
large static files under Ruby 1.9 using IO.copy_stream[1].
The EventMachine model has always had optimized static file
serving (using EM::Connection#stream_file_data[2]).
The EventMachine model (finally) gets conditionally deferred app
dispatch in a separate thread, as described by Ezra Zygmuntowicz
for Merb, Ebb and Thin[3].
[1] - http://euruko2008.csrug.cz/system/assets/documents/0000/0007/tanaka-IOcopy_stream-euruko2008.pdf
[2] - http://eventmachine.rubyforge.org/EventMachine/Connection.html#M000312
[3] - http://brainspl.at/articles/2008/04/18/deferred-requests-with-merb-ebb-and-thin
|
|
IO#readpartial on zero bytes will always return an empty
string, so ensure the emulator for Revactor does that as
well.
|
|
Even if it's just an empty file for now, it's critical in
case we ever add any code that returns user-visible strings
since Rack::Lint (and mere sanity) require binary encoding
for "rack.input".
|
|
Since deferred requests run in a separate thread, this affects
the root (non-deferred) thread as well since it may share
data with other threads.
|
|
Since we have conditional deferred execution in the regular
EventMachine concurrency model, we can drop this one.
This concurrency model never fully worked due to lack of
graceful shut downs, and was never promoted nor supported, either.
|
|
Merb (and possibly other) frameworks that support conditionally
deferred app dispatch can now use it just like Ebb and Thin.
http://brainspl.at/articles/2008/04/18/deferred-requests-with-merb-ebb-and-thin
|
|
|
|
* avoid needless links to /Rainbows.html
* keepalive_timeout has been 5 seconds by default for a while
* update "Gemcutter" references to "RubyGems.org"
|
|
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.
|
|
|
|
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.
|
|
Rack allows anything as the status, as long as it
returns a valid status integer on status.to_i.
|
|
* maint:
Rainbows! 0.91.1 - use a less-broken parser from Unicorn
|
|
This release fixes a denial-of-service vector for deployments
exposed directly to untrusted clients.
The HTTP parser in Unicorn <= 0.97.0 would trip an assertion
(killing the associated worker process) on invalid
Content-Length headers instead of raising an exception. Since
Rainbows! and Zbatery supports multiple clients per worker
process, all clients connected to the worker process that hit
the assertion would be aborted.
Deployments behind nginx are _not_ affected by this bug, as
nginx will reject clients that send invalid Content-Length
headers.
The status of deployments behind other HTTP-aware proxies is
unknown. Deployments behind a non-HTTP-aware proxy (or no proxy
at all) are certainly affected by this DoS.
Users are strongly encouraged to upgrade as soon as possible,
there are no other changes besides this bug fix from Rainbows!
0.91.0 nor Unicorn 0.97.0
This bug affects all previously released versions of Rainbows!
and Zbatery.
|
|
We can use the new HttpResponse.header_string method now
instead of writing an empty body.
|
|
This should be faster for serving static files and proxying IO
objects such as sockets/pipes. Unfortunately we cannot use this
reliably with non-blocking frameworks since IO.copy_stream will
release the GVL to block on I/O (rather than yielding a fiber
or returning from a callback).
Can't do HTTP/1.1 Range support, though :/
|
|
This will make it easier to use body#to_path if possible since
some concurrency models like EventMachine have optimized code
paths for serving static files.
|
|
http_response and http_server are never NOT loaded when
"rainbows" is required.
|
|
This gives us the option to use non-TCPSocket-derived
IO-ish objects in the future, whatever that may be...
|
|
Every concurrency model does this the same way.
This removes the Rainbows::Const::LOCALHOST constant and
may break some existing apps that rely on it.
|
|
It's generally dangerous to do so regardless of language and
Ruby 1.9.2dev is stricter about this sort of behaviour.
|
|
Unicorn 0.97.0 has a bunch of internal cleanups and small fixes
and this is mainly to resync with those changes.
keepalive_timeout now defaults to 5 seconds (from 2 seconds
previous). This should help out clients on slower connections.
Some small fixes and cleanups:
* Rainbows::Fiber::IO objects may leak if a rare app uses them
explicitly with FiberSpawn/FiberPool-only (not RevFiberSpawn)
* quiet down ENOTCONN handling, there's nothing we can do about
this error so we won't fill our logs with it.
|
|
The previous 2 second default was not enough for folks on slow
connections where our OS socket buffers would've masked the time
it took to write out larger responses.
ref: <20100219220904.GA11377@dcvr.yhbt.net>
|
|
Just create an empty string instead and let Unicorn::HttpParser
allocate it internally to whatever size is needed.
|
|
No point in having extra code around for platforms we
don't care about.
|
|
instance_variable_{set,get} are faster, but equally ugly
|
|
|
|
Since we deal with untrusted/non-local clients, those clients
may disconnect at inopportune times and leave us with ENOTCONN
when we try to call getpeername(2)
|
|
For the very rare apps out there using Rainbows::Fiber::IO, the
FiberSpawn and FiberPool (but not RevFiberSpawn) models could
leak memory if the app-created Rainbows::Fiber::IO objects
were dereferenced without being removed from the RD/WR hashes.
|
|
commit a5f4d11cdb9465b1ffa2892b3d84ee53b8962930 in unicorn.git
switched all ivars to struct members for ease-of-hacking and
object size.
|
|
When available (Ruby 1.9), we can use Hash#compare_by_identity
to improve performance.
|
|
* rack-1.1:
http_response: disallow blank, multi-value headers
|
|
Rev 0.3.2 makes performance with Threads* under Ruby 1.8
tolerable.
|
|
The HeaderHash optimizations in Rack 1.1 interact badly with
Rails 2.3.5 (and possibly other frameworks/apps) which set
multi-value "Set-Cookie" headers without relying on the proper
methods provided by Rack::Utils.
While this is an issue with Rails not using properly, there
may be similar apps that make this mistake and Rack::Lint
does not guard against it.
Rack-ML-Ref: <20100105235845.GB3377@dcvr.yhbt.net>
|
|
This release contains minor bugfixes/compatibility improvements
for ThreadSpawn, ThreadPool and EventMachine users.
Excessive error messages from spurious wakeups using
ThreadSpawn/ThreadPool under most platforms are silenced. Only
Ruby 1.9 users under Linux were unaffected by this bug.
EventMachine users may now use EM::Deferrable objects in
responses, vastly improving compatibility with existing
async_sinatra apps.
|
|
Some async apps rely on more than just "async.callback" and
make full use of Deferrables provided by the EM::Deferrable
module. Thanks to James Tucker for bringing this to our
attention.
|
|
Under all MRI 1.8, a blocking Socket#accept Ruby method (needs
to[1]) translate to a non-blocking accept(2) system call that may
wake up threads/processes unnecessarily. Unfortunately, we
failed to trap and ignore EAGAIN in those cases.
This issue did not affect Ruby 1.9 running under modern Linux
kernels where a _blocking_ accept(2) system call is not (easily,
at least) susceptible to spurious wakeups. Non-Linux systems
running Ruby 1.9 may be affected.
[1] - using a blocking accept(2) on a shared socket with
green threads is dangerous, as noted in
commit ee7fe220ccbc991e1e7cbe982caf48e3303274c7
(and commit 451ca6997b4f298b436605b7f0af75f369320425)
|
|
This release should fix ThreadSpawn green thread blocking issues
under MRI 1.8. Excessive socket closing is avoided when using
Thread* models with Sunshowers (or clients disconnecting
during uploads).
There is a new RevFiberSpawn concurrency model which combines
Rev with the traditional FiberSpawn model.
|
|
No point in becoming the straw that causes a rehash
since hardly anybody uses it.
|
|
|
|
We'll export this across the board to all Rack applications
to sleep with. This provides the optimum method of sleeping
regardless of the concurrency model you choose. This method
is still highly not recommended for pure event-driven models
like Rev or EventMachine (but the threaded/fiber/actor-based
variants are fine).
|