Date | Commit message (Collapse) |
|
Latest and greatest :D
|
|
New sendfile gem will give us IO#trysendfile.
We might as well use and test the latest and greatest
versions of everything else since thats what users
pull in by default.
|
|
The Cramp::Controller namespace is gone.
|
|
This conflicts with ports clients may automatically use
in the ephemeral range.
This reverts commit c9a7560bb684bbdadb641ebc7597303f38c37d4f.
|
|
This will help prevent us from breaking :pool_size in the
future.
|
|
It's too long especially since XEpollThreadPool is planned :>
|
|
It supports IPv6 and pulls in a better Kgio. Since Unicorn
defaults to ":tcp_nopush => true", we need to flip it back
to false to be compatible with the types of apps Rainbows!
is targetted as.
|
|
ed can do in-place editing portably, unlike sed.
|
|
We can't work around it effectively in the C extension
itself. This requires the latest sleepy_penguin gem.
|
|
It's Linux-only, after all
|
|
Binding to a random port is much easier this way
|
|
Some users never, ever accept uploads, so we should test
for it.
|
|
epoll is Linux-only right now. kqueue probably isn't worth
supporting directly (and even direct epoll support is debatable
given the current GVL situation)
|
|
Edge-triggered epoll concurrency model with blocking accept() in
a (hopefully) native thread. This is recommended over Epoll for
Ruby 1.9 users as it can workaround accept()-scalability issues
on multicore machines.
|
|
We can eliminate the State module to simplify our code
since 1.3.x keeps better track of things.
|
|
chunked Transfer-Encoding is only valid for HTTP/1.1
|
|
Or at least it should :)
|
|
we need to get in the habit of using this more
|
|
Coolio and EventMachine only use level-triggered epoll,
but being Rainbows!, we live on the EDGE!
|
|
This makes content-md5 tests much faster since we
no longer wait for the server to to timeout.
|
|
normal signals can get lost easily :<
|
|
We always try to track the latest and greatest. We've also
updated the test to actually test concurrency since
rack-fiber_pool reuses recent fibers now.
|
|
We need to ensure this esoteric feature keeps working for some
people.
|
|
We cannot trigger on_read events and invoke the HTTP parser and
modify @env while we're waiting for an application to run
async.callback. We also need to clear (and *maybe* re-set)
@deferred if we're writing from async.callback
|
|
The lack of an equivlent to EM::Deferrable prevents us from
doing streaming/trickling responses, but a one-shot body
should work fine for Coolio and generating dynamic responses.
|
|
We check the return code anyways, and spewing random binary
data to the terminal with verbosity on is not a good idea.
|
|
We can't possibly keep track of all sub-dependencies,
so only declare primary dependencies until we find
a known problem with a sub-dependency.
|
|
I realize this lock overly covers different versions of
Ruby, but it's simple and we don't need to invoke isolate
too often (we hope).
|
|
It's out and it works, so why not.
|
|
We need to split out Cramp tests to Isolate to a
different path, which sucks, but oh well. Cramp
hasn't had a release in a while...
|
|
async.callback will be useful with Coolio (and more!) soon, so
ensure it works as well as the rest of Rainbows!
|
|
Nagle's algorithm is harmful with the write-write-read sequence
during keepalive, so we disable it performance for users using
keepalive. We always write headers with a separate write
because Rack response bodies may not always be ready for writing
when headers are.
This requires Unicorn 3.3.0
|
|
This means we can remove Time.now.httpdate in the next commit
|
|
This is useful for clients that specify a bad range,
we can preserve the connection for them to specify
a good response.
|
|
416 responses without a body should respond with a zero
Content-Length and a Content-Range that allows clients
to specify a proper range in the future.
rfc2616, section 14.16 says:
> A server sending a response with status code 416 (Requested
> range not satisfiable) SHOULD include a Content-Range field
> with a byte-range- resp-spec of "*". The instance-length
> specifies the current length of the selected resource.
|
|
It's not appropriate to use AppPool middleware with
these. It was disabled for RevThread*, too.
|
|
Although curl did not complain, 206 is the correct error
code for partial HTTP responses.
|
|
After beefing up and enabling byte range tests for "sendfile"
(and no just IO.copy_stream), we noticed threaded-Coolio
variants did not handle invalid byte ranges correctly.
|
|
Tests for checking the Content-Range were totally broken,
but fortunately the code itself works.
|
|
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.
|
|
This will allow servers to limit the number of keepalive
requests that can be made over a single connection to
prevent denial-of-service and also to improve fairness
in load-balancing.
|
|
We still use and define Rev internally, but that's
mostly just manual labor of converting stuff over.
|
|
This requires manual verification :<
|
|
We need to be able to set this with keepalive_timeout
simultaneously.
|
|
We need to ensure the first worker has started and is
running before attempting to signal the reload.
|
|
The worker process may fork before the original process
is killed during daemonization.
|
|
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.
|
|
It still burns CPU at the first sign of doing anything
interesting, so stop it. Ruby 1.9 is the future :P
|
|
Unicorn 3.2.1 gives us an improved HttpParser#next? that
preserves state until the next HttpParser#parse call.
|
|
This was causing unrelated requests to get killed every
+timeout+ seconds, instead of only the ones that were
running too long.
Noticed-by: ghazel@gmail.com
ref:
http://mid.gmane.org/AANLkTi=7OhyTwkHsp_rXU7Gp1PokihiQ9bJigpO-BfN6@mail.gmail.com
|