about summary refs log tree commit homepage
path: root/lib/rainbows/dev_fd_response.rb
DateCommit message (Collapse)
2011-02-06minimize &block usage for yield
No need to allocate a proc every time when we can just yield much more efficiently.
2011-01-20dev_fd_response: garbage reduction
Constant strings mean the runtime won't have to allocate new objects all the time since GC is currently the biggest performance problem of Ruby 1.9.x in my experience.
2011-01-19dev_fd_response: do not send chunks to 1.0 clients
chunked Transfer-Encoding is only valid for HTTP/1.1
2011-01-19remove support for X-Rainbows-* headers
We guarantee the Rack env will exist for the duration of the request/response cycle, so we can just tweak "rainbows.autochunk".
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.