about summary refs log tree commit homepage
path: root/lib/rainbows/dev_fd_response.rb
DateCommit message (Collapse)
2011-01-07more consistent use/avoidance of HeaderHash
Rack::Utils::HeaderHash is still expensive, so avoid forcing it on users since we can assume app/library authors use normally-cased HTTP headers.
2011-01-07favor Hash#include? for some existence checks
Hash#[] is slightly slower on the miss case due to calling Hash#default (but faster for the hit case, probably because it is inlined in 1.9).
2010-12-28dev_fd_response: pass files straight through
No need to wrap regular files
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-19upgrade to Kgio 2.x and Unicorn 3.x
Kgio 2.0.0 has a superior API and less likely to conflict or blow up with other applications. Unicorn 3.x requires Kgio 2.x, too.
2010-10-22dev_fd_response: do not wrap for Fiber-aware IOs
Applications may use wait_readable-aware methods directly to work with Rainbows!
2010-08-17avoid EBADF with certain middlewares when proxying
First off we use an FD_MAP to avoid creating redundant IO objects which map to the same FD. When that doesn't work, we'll fall back to trapping Errno::EBADF and IOError where appropriate.
2010-08-13dev_fd_response: weaken /dev/fd check for compatibility
/dev/fd/0 may not be stat()-able on some systems after dropping permissions from root to a regular user. So just check for "/dev/fd" which seems to work on RHEL 2.6.18 kernels. This also allow us to be used independently of Unicorn in case somebody ever feels the compelling need to /close/ stdin.
2010-07-29revactor: Actor-aware dev_fd_response proxying
Proxying regular Ruby IO objects while Revactor is in use is highly suboptimal, so proxy it with an Actor-aware wrapper for better scheduling.
2010-07-19ensure stream response bodies get closed
Some middlewares such as Clogger rely on wrapping the body having the close method called on it for logging.
2010-07-19rev + em: more easily allow Content-Length in pipe responses
If a response proxying a pipe (or socket) includes a Content-Length, do not attempt to outsmart the application and just use the given Content-Length. This helps avoid exposing applications to weird internals such as env["rainbows.autochunk"] and X-Rainbows-* response headers.
2010-07-19dev_fd_response: remove needless begin block
2010-07-19no need to pass 'rb' as File.open flags
IO#read always returns a binary string buffer if passed an explicit length to read, and we always do that. This is a small garbage reduction.
2010-06-30dev_fd_response: avoid redeclaring Rainbows module
slowly cleaning up the generated RDoc
2010-06-21dev_fd_response: disable under Rubinius for now
We can't use it effectively in Rubinius yet, and it's broken due to the issue described in: http://github.com/evanphx/rubinius/issues/379
2010-06-21dev_fd_response: cleanup and reorganization
There's no need to #dup the middleware object, just use a custom Rainbows::DevFdResponse::Body object.
2010-06-18avoid needless HeaderHash#to_hash calls
HeaderHash objects can only be used as headers without violating Rack::Lint in Rack 1.1.0 or later.
2009-12-22new RevFiberSpawn concurrency model
This is like the traditional FiberSpawn, but more scalable (but not necessarily faster) as it can use epoll or kqueue.
2009-11-25add FiberPool concurrency model
This is another Fiber-based concurrency model that can exploit a streaming "rack.input" for clients. Spawning Fibers seems pretty fast, but maybe there are apps that will benefit from this.
2009-11-25add FiberSpawn concurrency model
This one seems a easy to get working and supports everything we need to support from the server perspective. Apps will need modified drivers, but it doesn't seem too hard to add more/better support for wrapping IO objects with Fiber::IO.
2009-10-18rev: async response bodies with DevFdResponse middleware
This new middleware should be a no-op for non-Rev concurrency models (or by explicitly setting env['rainbows.autochunk'] to false). Setting env['rainbows.autochunk'] to true (the default when Rev is used) allows (e)poll-able IO objects (sockets, pipes) to be sent asynchronously after app.call(env) returns. This also has a fortunate side effect of introducing a code path which allows large, static files to be sent without slurping them into a Rev IO::Buffer, too. This new change works even without the DevFdResponse middleware, so you won't have to reconfigure your app. This lets us epoll on response bodies that come in from a pipe or even a socket and send them either straight through or with chunked encoding.