Date | Commit message (Collapse) |
|
Similar to what we do in EM, this avoid unnecessary
conditional logic inside more frequently used code paths.
|
|
Some apps never serve static files nor proxy pipes/sockets,
so they'll never need to deal with deferred responses.
|
|
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.
|
|
When available (Ruby 1.9), we can use Hash#compare_by_identity
to improve performance.
|
|
Due to the addition of keepalive_timeouts, it's safer to
pay a performance penalty and use a hash here instead.
|
|
This is a bit trickier than the rest since we have to ensure
deferred (proxied) responses aren't nuked.
|
|
This will make things easier to manage with more
Rev-based concurrency models.
|
|
Since the HTTP parser is frozen during app dispatch, there's
no point in checking for HTTP keepalive sooner. Of course we
check G.alive as late as possible since we could've received a
:QUIT signal while app.call was running.
|
|
It turns out neither the EventMachine and Rev classes
checked for master death in its heartbeat mechanism.
Since we managed to forget the same thing twice, we
now have a test case for it and also centralized the
code to remove duplication.
|
|
We don't use it in EventMachine since EM has its own
built-in ways to handle deferred bodies.
|
|
This module will be reused in upcoming Rev-derived concurrency
models.
|
|
We depend on the ability to create listeners from existing IO
objects here.
|
|
Rack::Lint requires File::exist? to be true on this, so
there's no need to expand the path name to resolve it
here.
|
|
Graceful quit means we finish sending everything we have before
exiting. Additionally, only signal quits after we've queued
the error response up.
|
|
EventMachine and Rev models seem to be able to share a lot of
common code, so lets share. We may support Packet in the
future, too, and end up with a similar programming model there
as well.
|
|
Odd that Ruby didn't barf on this until now...
|
|
Since HTTP/0.9 responses have no headers to write, the
on_write_complete handler we rely on never got triggered,
leading to additional reads to never get queued up.
Additionally, we need to explicitly detect and close client
sockets if we've written the last response body since HTTP/0.9
clients never know when it's time to close a connection.
|
|
This was blindly copied and pasted from the Revactor code.
|
|
|
|
The "async" moniker wasn't appropriate since this API also
handles static files without slurping, so "deferred" is a more
appropriate term (even if I have trouble speling words with
double conssonants in them).
The DeferredResponse.write method now emulates the
HttpResponse.write method for consistency.
|
|
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.
|
|
Oops, looks like they were never implemented at all.
|
|
Handling HTTP pipelining through recursion is not good since
several hundred kilobytes worth of GET/HEAD requests can be a
LOT of GET/HEAD requests...
|
|
This leaves us vulnerable to stack overflows through excessive
pipelining. The next patch will fix things hopefully.
|
|
We use the "G" global constant from the Rev model everywhere
to simplify things a little.
Test cases are more consistent now, too.
|
|
on_write_complete has no chance of being called
there so remove the unnecessary ensure statement
|
|
|
|
We should try to send 400s back to the client if possible.
|
|
|
|
There is no TeeInput (streaming request body) support, yet,
as that does not seem fun nor easy to do (or even possible
without using Threads or Fibers or something to save/restore
the stack...)
|