| Date | Commit message (Collapse) |
|---|
|
This was noticed by running under Ruby 1.9.2-preview3
|
|
We'll be switching to Isolate and shell-based tests
since the old test/unit-based Rails test was basically
a shell script written in Ruby.
|
|
This allows us to gets rid of the Rack 1.0.1 dependency when
running Rails tests since previous versions of Rails 2.3.x
needed Rack 1.0.1, where as Rails 2.2.x and below could be used
with any version of Rack (under Unicorn only).
|
|
This should allow "unicorn_rails" to be used seamlessly
with Rails 3 projects which package config.ru for you.
|
|
|
|
Isolate 2.0.0 appears to have quietly released, so update
the docs for it. Fix capitalization while we're at it, too.
|
|
|
|
This middleware allows configurable out-of-band garbage
collection outside of the normal request/response cycle.
It offers configurable paths (to only GC on expensive actions)
and intervals to limit GC frequency.
It is only expected to work well with Unicorn, as it would
hurt performance on single-threaded servers if they
have keepalive enabled. Obviously this does not work well
for multi-threaded or evented servers that serve multiple
clients at once.
|
|
|
|
This may be expanded to cover other similar tools, as well,
including tools that don't use RubyGems.
|
|
This is allowed by RFC 2616, section 2.2, where spaces and
horizontal tabs are counted as linear white space and linear
white space (not just regular spaces) may prefix field-values
(section 4.2).
This has _not_ been a real issue in ~4 years of using this
parser (starting with Mongrel) with clients in the wild.
Thanks to Iñaki Baz Castillo for pointing this out.
|
|
Modern version of Unicorn have working_directory available and
should use that instead.
|
|
|
|
Starting with this release, we'll always load Rack up front at
startup.
Previously we had complicated ways to avoid loading Rack until
after the application was loaded to allow the application to
load an alternate version of Rack. However this has proven too
error-prone to be worth supporting even though Unicorn does not
have strict requirements on currently released Rack versions.
If an app requires a different version of Rack than what Unicorn
would load by default, it is recommended they only install that
version of Rack (and no others) since Unicorn does not have any
strict requirements on currently released Rack versions.
Rails 2.3.x users should be aware of this as those versions are
not compatible with Rack 1.1.0.
If it is not possible to only have one Rack version installed
"globally", then they should either use Isolate or Bundler and
install a private version of Unicorn along with their preferred
version of Rack. Users who install in this way are recommended
to execute the isolated/bundled version of Unicorn, instead of
what would normally be in $PATH.
Feedback/tips to mailto:mongrel-unicorn@rubyforge.org from
Isolate and Bundler users would be greatly appreciated.
|
|
It's too complicated and error-prone to allow apps to use a
different version of Rack than the one Unicorn would otherwise
use by default.
If an app requires a different version of Rack than what Unicorn
would load by default, it is recommended they only install that
version of Rack (and no others) since Unicorn does not have any
strict requirements on currently released Rack versions.
If it is not possible to only have one Rack version installed
globally, then they should either use Isolate or Bundler and
install a private version of Unicorn along with their preferred
version of Rack. Users who install in this way are recommended
to execute the isolated/bundled version of Unicorn, instead of
what would normally be in $PATH.
Feedback/tips to mailto:mongrel-unicorn@rubyforge.org from
Isolate and Bundler users would be greatly appreciated.
|
|
|
|
Deployments that suspend or hibernate servers should no longer
have workers killed off (and restarted) upon resuming.
For Linux users of {raindrops}[http://raindrops.bogomips.org/]
(v0.2.0+) configuration is easier as raindrops can now
automatically detect the active listeners on the server
via the new Unicorn.listener_names singleton method.
For the pedantic, chunked request bodies without trailers are no
longer allowed to omit the final CRLF. This shouldn't affect
any real and RFC-compliant clients out there. Chunked requests
with trailers have always worked and continue to work the same
way.
The rest are mostly small internal cleanups and documentation
fixes. See the commit logs for full details.
|
|
It makes the HTML page too big and busy.
|
|
This is useful as a :listeners argument when setting up
Raindrops::Middleware (http://raindrops.bogomips.org/),
as it can be done automatically.
|
|
|
|
|
|
'tmp' may be a directory when using rake-compiler (or isolate),
so avoid naming a file 'tmp'
|
|
* maint:
unicorn 0.97.1 - fix HTTP parser for Rainbows!/Zbatery
http: negative/invalid Content-Length raises exception
|
|
|
|
HTTP requests without trailers still need a CRLF after the last
chunk, that is: it must end as: "0\r\n\r\n", not "0\r\n". So
we'll always pretend there are trailers to parse for the
sake of TeeInput.
This is mostly a pedantic fix, as the two bytes in the socket
buffer are unlikely to trigger protocol errors.
|
|
|
|
|
|
This release fixes a denial-of-service vector for derived
servers exposed directly to untrusted clients.
This bug does not affect most Unicorn deployments as Unicorn is
only supported with trusted clients (such as nginx) on a LAN.
nginx is known to reject clients that send invalid
Content-Length headers, so any deployments on a trusted LAN
and/or behind nginx are safe.
Servers affected by this bug include (but are not limited to)
Rainbows! and Zbatery. This bug does not affect Thin nor
Mongrel, as neither got the request body filtering treatment
that the Unicorn HTTP parser got in August 2009.
The bug fixed in this release could result in a
denial-of-service as it would trigger a process-wide assertion
instead of raising an exception. For servers such as
Rainbows!/Zbatery that serve multiple clients per worker
process, this could abort all clients connected to the
particular worker process that hit the assertion.
|
|
...instead of tripping an assertion.
This fixes a potential denial-of-service for servers exposed directly
to untrusted clients.
This bug does not affect supported Unicorn deployments as Unicorn is
only supported with trusted clients (such as nginx) on a LAN. nginx is
known to reject clients that send invalid Content-Length headers, so any
deployments on a trusted LAN and/or behind nginx are safe.
Servers affected by this bug include (but are not limited to) Rainbows!
and Zbatery. This does not affect Thin nor Mongrel which never got
request body filtering treatment that the Unicorn HTTP parser got in
August 2009.
|
|
...instead of tripping an assertion.
This fixes a potential denial-of-service for servers exposed directly
to untrusted clients.
This bug does not affect supported Unicorn deployments as Unicorn is
only supported with trusted clients (such as nginx) on a LAN. nginx is
known to reject clients that send invalid Content-Length headers, so any
deployments on a trusted LAN and/or behind nginx are safe.
Servers affected by this bug include (but are not limited to) Rainbows!
and Zbatery. This does not affect Thin nor Mongrel which never got
request body filtering treatment that the Unicorn HTTP parser got in
August 2009.
|
|
Trying to fix this issue again, as it seems to have been broken
again.
|
|
There is no need to be using autoload except for HttpResponse
which depends on Rack (which we want to load as late as
possible).
|
|
This will help ensure we use the same version of Rack the
application uses and avoid loading conflicting/incompatible
versions.
|
|
|
|
"ru" is the preferred name in Unicorn.builder, so we'll
match that to make things easier to follow.
|
|
Do not assume the user wants config.ru to be Encoding::BINARY
for 1.9.
This is a followup to a4a8bf7604d1c15c5a8fb9cb6be37e8bccb32e52
|
|
This is to ensure there are no namespace inconsistencies
|
|
We're one of the few forking apps that run into this rarely used
feature, so we'll document it here.
|
|
Avoid Tempfile.new(nil), which breaks under Ruby 1.9.2
and was probably a bad idea to begin with.
|
|
A bunch of small fixes related to startup/configuration and hot
reload issues with HUP:
* Variables in the user-generated config.ru files no longer
risk clobbering variables used in laucher scripts.
* signal handlers are initialized before the pid file is
dropped, so over-eager firing of init scripts won't
mysteriously nuke a process.
* SIGHUP will return app to original state if an updated
config.ru fails to load due to {Syntax,Load}Error.
* unicorn_rails should be Rails 3 compatible out-of-the-box
('unicorn' works as always, and is recommended for Rails 3)
* unicorn_rails is finally "working_directory"-aware when
generating default temporary paths and pid file
* config.ru encoding is the application's default in 1.9,
not forced to binary like many parts of Unicorn.
* configurator learned to handle the "user" directive outside
of after_fork hook (which will always remain supported).
There are also various internal cleanups and possible speedups.
|
|
It's part of the standard Ruby library and will always be loaded
by various modules (Rack::Utils, Tmpdir) so there's no point in
deferring it.
|
|
Allowing the "user" directive outside of after_fork reduces the
cognitive overhead for folks that do not need the complexity of
*_fork hooks. Using Worker#user remains supported as it offers
fine-grained control of user switching.
|
|
|
|
Do not assume the user wants config.ru to be Encoding::BINARY
for 1.9.
|
|
|
|
This lets us reuse code for Zbatery and Rainbows!, too.
|
|
It's a waste of memory bandwidth to do memcpy() when we know
Unicorn::HttpParser (via rb_str_resize()) will allocate new
memory for the string for us. An empty String is "free",
as we've already paid the Object cost regardless.
|
|
We'll use struct members exclusively from now on instead of
throwing ivars into the mix. This allows us to _unofficially_
support direct access to more members easily. Unofficial
extensions may include the ability to splice(2)/tee(2) for
better performance.
This also makes our object size smaller across all Ruby
implementations as well, too (helps Rainbows! out).
|
|
The temporary paths we create to mimic script/server-emulation
did not work when working_directory was used. Now we defer
path creation until after working_directory is bound.
|
|
|