Date | Commit message (Collapse) |
|
Although this behavior is mentioned on the documentation,
this was broken under EventMachine, Rev*, and Revactor.
Furthermore, we set the "Connection: close" header to allow the
client to optimize is handling of non-keepalive connections.
|
|
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.
|
|
Remove an unused constant.
|
|
No constant resolution changes, avoid redefining
modules needlessly since this is not meant to be
used standalone.
|
|
Trying to avoid adding singleton methods since it's too easily
accessible by the public and not needed by the general public.
This also allows us (or just Zbatery) to more easily add support
systems without FD_CLOEXEC or fcntl, and also to optimize
away a fcntl call for systems that inherit FD_CLOEXEC.
|
|
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).
|
|
When proxying pipes/sockets, it's possible for the Rev::IO#write
to fail and close our connection. In that case we do not want
our client to continue with the on_write_complete callback.
|
|
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.
|
|
Remove unnecessary include and also remove unnecessary
nesting.
|
|
It's slightly faster as theres no string to parse and also
no garbage format string to be discarded.
|
|
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).
|
|
Other concurrency models will eventually be able to use it, too.
|
|
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.
|
|
HeaderHash objects can only be used as headers without
violating Rack::Lint in Rack 1.1.0 or later.
|
|
Array#[] lookups are slightly faster under both rbx and 1.9,
and easier to read.
|
|
Since EventMachine and Rev shared the same logic for optimizing
and avoiding extra file opens for IO/File-ish response bodies,
so centralize that.
For Ruby 1.9 users, we've also enabled this logic so ThreadPool,
ThreadSpawn, WriterThreadPool, and WriterThreadSpawn can take
advantage of Rainbows::DevFdResponse-generated bodies while
proxying sockets.
|
|
We can use the new HttpResponse.header_string method now
instead of writing an empty body.
|
|
It gets in the way of Rev/EM-based models that won't use EvCore.
It doesn't actually do anything useful except making an extra
layer of indirection to follow.
|
|
We no longer explicitly close @input
|
|
Don't expect RevThreadPool to work with Rev <= 0.3.1, either.
|
|
It may make it harder to switch between concurrency models with
SIGHUP this way...
|
|
This should be like RevThreadSpawn except with more predictable
performance (but higher memory usage under low load).
|
|
iobuffer 0.1.3 already sets this.
|
|
|
|
Broken in 145185b76dafebe5574e6a3eefd3276555c72016
|
|
It can noticeably improve performance if available.
ref: http://rubyforge.org/pipermail/rev-talk/2009-November/000116.html
|
|
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.
|