Date | Commit message (Collapse) |
|
OpenSSL seeds its PRNG with the process ID, so if a process ID
is recycled, there's a chance of indepedent workers getting
repeated PRNG sequences over a long time period iff the same
PID is used.
This only affects deployments that meet both of the following
conditions:
1) OpenSSL::Random.random_bytes is called before forking
2) worker (but not master) processes are die unexpectedly
The SecureRandom module in Ruby (and Rails) uses the OpenSSL
PRNG if available. SecureRandom is used by Rails and called
when the application is loaded, so most Rails apps with
frequently dying worker processes are affected.
Of course dying worker processes are bad and entirely the
fault of bad application/library code, not the fault of
Unicorn.
Thanks for Alexander Dymo for reporting this.
ref: http://redmine.ruby-lang.org/issues/4579
|
|
The current versions of Ruby 1.8 do not reseed the PRNG after
forking, so we'll work around that by calling Kernel#srand.
ref: http://redmine.ruby-lang.org/issues/show/4338
|
|
Oops, changing a method definition for RDoc means code
needs to be updated, too :x
|
|
They should then recover and inherit writable descriptors
from the master when it respawns.
|
|
It's not needed for users, so avoid confusing them.
Unicorn itself is not intended to be an API, it just
hosts Rack applications.
|
|
Mainly formatting and such, but some wording changes.
|
|
|
|
Configurator itself supports user at the top-level.
|
|
Users keep both pieces if it's broken :)
|
|
File#size is available in 1.9.2
|
|
Ruby 1.8.* users should get the latest Ruby 1.8.7 anyways since
they contain critical bugfixes. We don't keep workarounds
forever since the root problem is fixed/worked-around in
upstream and people have had more than a year to upgrade Ruby.
|
|
We don't want to repeatedly reclose the same IOs
and keep raising exceptions this way.
|
|
They needlessly allocate Proc objects
|
|
* IPv6 support in the HTTP hostname parser and configuration
language. Configurator syntax for "listen" addresses should
be the same as nginx. Even though we support IPv6, we will
never support non-LAN/localhost clients connecting to Unicorn.
* TCP_NOPUSH/TCP_CORK is enabled by default to optimize
for bandwidth usage and avoid unnecessary wakeups in nginx.
* Updated KNOWN_ISSUES document for bugs in recent Ruby 1.8.7
(RNG needs reset after fork) and nginx+sendfile()+FreeBSD 8.
* examples/nginx.conf updated for modern stable versions of nginx.
* "Status" in headers no longer ignored in the response,
Rack::Lint already enforces this so we don't duplicate
the work.
* All tests pass under Ruby 1.9.3dev
* various bugfixes in the (mostly unused) ExecCGI class that
powers http://bogomips.org/unicorn.git
|
|
for i in `git ls-files '*.rb'`; do ruby -w -c $i; done
|
|
Oops! Ugh, not my day...
|
|
Oops!
|
|
This is much like how nginx does it, except we always require a
port when explicitly binding to IPv6 using the "listen"
directive. This also adds support to listen with an
address-only, which can be useful to Rainbows! users.
|
|
This reduces surprise when people (correctly) believe
removing an option from the config file will return
things back to our internal defaults.
|
|
It's actually harmless since Unicorn only supports "fast"
applications that do not trickle, and we don't do keepalive so
we'll always flush-on-close. This should reduce wakeups on the
nginx proxy server if nginx is over TCP. Mongrel 1.x had
TCP_CORK enabled by default, too.
|
|
We no longer blindly return 200 if the CGI returned another error
code. We also don't want two Status headers in our output since we
no longer filter it out.
|
|
Rainbows! can then use this to bypass luserspace given
the correct offset is set before hand and the file
is unlinked.
|
|
This may not be supported in the future...
|
|
Rack::Lint already stops apps from using it. If a developer
insists on it, then users who inspect their HTTP headers can
point and laugh at them for not using Rack::Lint!
|
|
We now close the client socket after closing the response body.
This does not affect most applications that run under Unicorn,
in fact, it may not affect any.
There is also a new v1.1.6 release for users who do not use
kgio.
|
|
Response bodies may capture the block passed to each
and save it for body.close, so don't close the socket
before we have a chance to call body.close
|
|
Certain applications that already serve hundreds/thousands of requests a
second should experience performance improvements due to
Time.now.httpdate usage being removed and reimplemented in C.
There are also minor internal changes and cleanups for Rainbows!
|
|
But allows small optimizations to be made to avoid
constant/instance variable lookups later :)
|
|
No need to preserve the response tuplet if we're just
going to unpack it eventually.
|
|
|
|
This will allow Rainbows! to set :tcp_nodelay=>true
and possibly other things in the future.
|
|
This can return a static string and be significantly
faster as it reduces object allocations and Ruby method
calls for the fastest websites that serve thousands of
requests a second.
It assumes the Ruby runtime is single-threaded, but that
is the case of Ruby 1.8 and 1.9 and also what Unicorn
is all about. This change is safe for Rainbows! under 1.8
and 1.9.
|
|
It's a minor garbage reduction, but nobody uses "$,", and
if they did, they'd break things in the Ruby standard library
as well as Rack, so let anybody who uses "$," shoot themselves
in the foot.
|
|
There are numerous improvements in the HTTP parser for
Rainbows!, none of which affect Unicorn-only users.
The kgio dependency is incremented to 2.1: this should avoid
ENOSYS errors for folks building binaries on newer Linux
kernels and then deploying to older ones.
There are also minor documentation improvements, the website
is now JavaScript-free!
(Ignore the 3.2.0 release, I fat-fingered some packaging things)
|
|
There are numerous improvements in the HTTP parser for
Rainbows!, none of which affect Unicorn-only users.
The kgio dependency is incremented to 2.1: this should avoid
ENOSYS errors for folks building binaries on newer Linux
kernels and then deploying to older ones.
There are also minor documentation improvements, the website
is now JavaScript-free!
|
|
We can just use a begin block at startup, this also makes life
easier on RDoc.
|
|
An unconfigured Rainbows! (e.g. Rainbows! { use :Base }) already
does keepalive and supports only a single client per-process.
|
|
This is the most important part of Unicorn documentation
for end users.
|
|
More config bloat, sadly this is necessary for Rainbows! :<
|
|
This release enables tuning the client_buffer_body_size to raise
or lower the threshold for buffering request bodies to disk.
This only applies to users who have not disabled rewindable
input. There is also a TeeInput bugfix for uncommon usage
patterns and Configurator examples in the FAQ should be fixed
|
|
Since modern machines have more memory these days and
clients are sending more data, avoiding potentially slow
filesystem operations for larger uploads can be useful
for some applications.
|
|
This has been broken since 2.0.x
Internal cleanups sometimes have unintended consequences :<
|
|
In case a request sends the header and buffer as one packet,
TeeInput relying on accounting info from StreamInput is harmful
as StreamInput will buffer in memory outside of TeeInput's
control.
This bug is triggered by calling env["rack.input"].size or
env["rack.input"].rewind before to read.
|
|
...and only Rainbows! This release fixes HTTP pipelining for
requests with bodies for users of synchronous Rainbows!
concurrency models.
Since Unicorn itself does not support keepalive nor pipelining,
Unicorn-only users need not upgrade.
|
|
It screws up keepalive for Rainbows! requests with a body.
|
|
Rewindable "rack.input" may be disabled via the
"rewindable_input false" directive in the configuration file.
This will violate Rack::Lint for Rack 1.x applications, but can
reduce I/O for applications that do not need a rewindable
input.
This release updates us to the Kgio 2.x series which should play
more nicely with other libraries and applications. There are
also internal cleanups and improvements for future versions of
Rainbows!
The Unicorn 3.x series supercedes the 2.x series
while the 1.x series will remain supported indefinitely.
|
|
There's no difference because of the \A anchor, but sub!
is doesn't loop so it's simpler.
|
|
No need to accept any number of args, that could hide bugs in
applications that could give three or more arguments. We also
raise ArgumentError when given a negative length argument to
read.
|
|
This release updates us to the Kgio 2.x series which should play
more nicely with other applications. There are also bugfixes
from the 2.0.1 release and a small bugfix to the new StreamInput
class.
The Unicorn 3.x series will supercede the 2.x series
while the 1.x series will remain supported indefinitely.
|
|
Any calls to read with an explicit zero length now returns an
empty string. While not explicitly specified by Rack::Lint,
this is for compatibility with StringIO and IO methods which
are common in other web servers.
|