Date | Commit message (Collapse) |
|
Those are entirely single-threaded during the application
dispatch phase.
|
|
While gawk can handle binary data, other awks cannot, so
use tr(1) to filter out non-printable characters from the
WebSocket message. We need to send a bigger message, too,
since tr(1) output is buffered and there's no portable way
to unbuffer it :<
|
|
|
|
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.
|
|
We need to remember to close response bodies even if
a client aborts the connection, since body.close can
trigger interesting things like logging and such...
|
|
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).
|
|
Some middlewares such as Clogger rely on wrapping the body
having the close method called on it for logging.
|
|
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.
|
|
Using EM.enable_proxy with EM.attach seems to cause
EM::Connection#receive_data callbacks to be fired before the
proxy has a chance to act, leading the first few chunks of data
being lost in the default receive_data handler. Instead
just rely on EM.watch like the chunked pipe.
|
|
This avoids costant resolution problems on client EOF
during input processing.
|
|
|
|
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...
|
|
We shouldn't ever spew errors to the stderr/logger
on client disconnects (ECONNRESET/EPIPE/etc...).
|
|
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.
|
|
This still needs work and lots of cleanup, but the basics are
there. The sendfile 1.0.0 RubyGem is now safe to use under MRI
1.8, and is superior to current (1.9.2-preview3) versions of
IO.copy_stream for static files in that it supports more
platforms and doesn't truncate large files on 32-bit platforms.
|
|
|
|
|
|
We only read from the IO pipe and never write to it
|
|
They're ugly and potentially non-portable to other servers.
They also make Unicorn + Rubinius unhappy, which makes us
unhappy as well.
|
|
Everything should be working under Ruby 1.9.2(-preview3) now.
|
|
Oops, looks like 1.9.1 exports the RUBY_ENGINE constant.
|
|
Rubinius still has a few issues that prevent 100% support,
but it basically works if log rotation or USR2 upgrades aren't
required. Tickets for all known issues for Rubinius have
been filed on the project's issue tracker.
* rbx does not support -i/-p yet, so rely on MRI for that
* "io/nonblock" is missing
* avoiding any optional Gems for now (EM, Rev, etc..)
|
|
|
|
|
|
Some folks can now show off their Rainbows! installation
|
|
Don't try to redirect until we know our FIFO consumers are
ready for us. This only seems to happen with bash and not
ksh...
commit d0a0883eaaeec37800ca5cd07647b7b66a00c453 in Unicorn
|
|
|
|
Apparently this document was completely forgotten over the
course of development and never properly put on the website.
The test suite is one of my favorite parts of Rainbows! and
allows us to test the server as real clients would hit it.
|
|
It was missing dependencies on the first run
|
|
We don't need tmp/ in our top level directory
|
|
Sinatra 0.9.4 does not appear to be compatible with
Ruby 1.9.2...
|
|
Some testers (like myself) use http_proxy when isolating
gems to avoid wasting bandwidth, but we don't proxy requests
to localhost.
|
|
It's useful given all the Gems we support but don't have hard
installation dependencies on.
|
|
This lets most concurrency models understand and process
X-Sendfile efficiently with IO.copy_stream under Ruby 1.9.
EventMachine can take advantage of this middleware under
both Ruby 1.8 and Ruby 1.9.
|
|
While these models are designed to work with IO.copy_stream
under Ruby 1.9, it should be possible to run them under Ruby
1.8 without returning corrupt responses. The large file
response test is beefed up to compare SHA1 checksums of
the served file, not just sizes.
|
|
It hasn't been used since the first month of development
when we started using FIFOs
|
|
it's hard to make this test reliable, but try to
add a small fudge factor based on the MRI default
GC malloc limit.
|
|
|
|
This allows it to be a symlink to /dev/shm or similar
|
|
curl < 7.18.0 did not check for errors when doing chunked
uploads. Unfortunately some distros are slow moving and
bundle ancient versions of curl.
|
|
since we don't set maximum time boundaries, just rely on
the logs to properly log the dead processes.
|
|
since we've already waited for time to elapse, there's no
point in watching the upper limit here
|
|
This test can cause a lot of I/O, especially when
run in parallel. Just rely on the fixed rsha1 code
to compute the SHA1 of the response.
|
|
non-random_blob arguments weren't being taken into account
correctly :x
|
|
slow test runners can buffer us and bloat memory usage
unpredictably when tests are run under load
|
|
On busy sytems, this timing-sensitive test is likely to fail,
so give it some extra slack
|