Date | Commit message (Collapse) |
|
We use Cool.io internally everywhere now, but preserve
Rev-based models for anybody using them.
|
|
Some middlewares require the Rack env to be preserved all
the way through to close, so we'll ensure all request models
preserve it.
We also need to better response body wrappers/proxies always get
fired properly when returning. IO.copy_stream and "sendfile"
gem users could hit cases where wrappers did not fire properly.
|
|
It's ugly to look at.
|
|
One line of code saved! We'll also avoid loading
DeferredChunkResponse which is rarely needed
(unlike DeferredResponse).
|
|
The HttpParser#next? method will come with keepalive protection
for Rainbows!, which can prevent clients from monopolizing a
server with excessive pipelining/keepalive requests.
|
|
This makes constant resolution more predictable, we hope.
|
|
All synchronous models have this fixed in unicorn 3.0.1,
so only Rev and EventMachine-based concurrency models
require code changes.
|
|
Errno::EAGAIN is still a problem under Ruby 1.9.2, so try harder
to avoid it and use kgio methods. Even when 1.9.3 is available,
kgio will still be faster as exceptions are slower than normal
return values.
|
|
The underlying symbolic names are easier to type and
recommended.
|
|
These allow for small reductions in the amount of variables
we have to manage, more changes coming with later Unicorns.
|
|
kgio_trywrite is superior if it is available.
|
|
It removes the burden of byte slicing and setting file
descriptor flags. In some cases, we can remove unnecessary
peeraddr calls, too.
|
|
Proxying IO objects with threaded Rev concurrency models
occasionally failed with pipelined requests (t0034). By
deferring the on_write_complete callback until the next
"tick" (similar to what we do in Rev::Client#write),
we prevent clobbering responses during pipelining.
|
|
Our keep-alive timeout mechanism does not need to kick in and
redundantly close when a client. Fortunately there is no danger
of redundantly closing the same numeric file descriptors (and
perhaps causing difficult-to-track-down errors).
|
|
With sendfile enabled, we must avoid writing headers (or normal,
non-file responses) while a file is deferred for sending. This
means we must disable processing of new requests while a file
is deferred for sending and use the on_write_complete callback
less aggressively.
|
|
It's a destructive method, and it does more than just parsing.
|
|
We don't send headers with HTTP/0.9 connections, so the IO write
watchers in Rev are never enabled if we're proxying IO objects
as the response body.
|
|
The FileStreamer class of EventMachine (and by extension
NeverBlock) unfortunately doesn't handle this. It's possible
to do with Revactor (since it uses Rev under the covers),
but we'll support what we can easily for now.
|
|
Middlewares like Clogger may wrap Rack::File responses
with another body that responds to to_path and still
rely on #close to trigger an action (writing out the log
file).
|
|
Similar to what we do in EM, this avoid unnecessary
conditional logic inside more frequently used code paths.
|
|
This makes it easier to write proxies for slow clients that
benefit from keep-alive. We also need to be careful about
non-HTTP/1.1 connections that can't do keepalive, now.
|
|
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.
|
|
Rack::File already sets the Content-Length header for us,
so there's no reason to ever set this ourselves.
|
|
This will give each concurrency model more control over
particular code paths and serving static files.
|
|
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.
|
|
Cramp monkey patches Rainbows internals for WebSockets
support and we forgot about it. Add a new integration
test to ensure this continues to work in the future
(and force us to update the test for newer Cramp).
|
|
Fortunately this only affects the hardly-used FiberSpawn and
FiberPool concurrency models, and also unreleased revisions of
Rev. 1.9 encoding is tricky to handle right when doing I/O in
Ruby...
|
|
non-blocking write() may cause kernel buffers to be allocated
behind the scenes, so retry the write() even if it's short
because it may succeed the next time around.
|
|
We shouldn't ever spew errors to the stderr/logger
on client disconnects (ECONNRESET/EPIPE/etc...).
|
|
There's no need to ever change the underlying offset of a file
descriptor when using sendfile(), so don't. This allows us to
avoid contention in the kernel/filesystem and eventually reuse
the same filesystem file descriptor for serving multiple
requests.
|
|
We need to load sendfile-using parts after the
"sendfile" library is loaded.
|
|
This hopefully allows the "sendfile" gem to be required
anywhere in the Rainbows!/Unicorn config file, and not
have to be required via RUBYOPT or the '-r' command-line
switch.
We also modularize HttpResponse and avoids singleton methods
in the response path. This (hopefully) makes it easier for
individual concurrency models to share code and override
individual methods.
|
|
Avoid confusing people with an overloaded method name
|
|
This should improve performance for static file responses.
|
|
|
|
|
|
I was originally experimenting with setsockopt to increase the
kernel buffer sizes in a loop, but the benefits were negligible
at best.
|
|
For small responses that can fit inside a kernel socket
buffer, copying that data into an IO::Buffer object is
a waste of precious memory bandwidth.
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
Due to the addition of keepalive_timeouts, it's safer to
pay a performance penalty and use a hash here instead.
|
|
No point in rewinding the NULL_IO especially when most requests
use them instead of bodies that actually have something.
|
|
This is a bit trickier than the rest since we have to ensure
deferred (proxied) responses aren't nuked.
|
|
Seems to pass all tests, but that may only mean our
test cases are lacking...
|
|
It'll make development of future ev_core-derived things
easier, hopefully.
|
|
In the upcoming RevThread* models, the parser may be parsing
other requests already by the time DeferredResponse is called.
|
|
This will make things easier to manage with more
Rev-based concurrency models.
|