| Date | Commit message (Collapse) |
|---|
|
This maintenance release is intended for users of Rainbows! and
Zbatery servers (and anybody else using Unicorn::HttpParser).
This memory leak DID NOT affect Unicorn itself: Unicorn always
allocates the HttpParser once and always reuses it in every
sequential request.
This leak affects applications that repeatedly allocate a new
HTTP parser. Thus this bug affects _all_ deployments of
Rainbows! and Zbatery. These servers allocate a new parser for
every client connection to serve clients concurrently.
I misread the Data_Make_Struct()/Data_Wrap_Struct()
documentation and ended up passing NULL as the "free" argument
instead of -1, causing the memory to never be freed.
From README.EXT in the MRI source which I misread:
> The free argument is the function to free the pointer
> allocation. If this is -1, the pointer will be just freed.
> The functions mark and free will be called from garbage
> collector.
|
|
First off, this memory leak DOES NOT affect Unicorn itself.
Unicorn allocates the HttpParser once and always reuses it
in every sequential request.
This leak affects applications which repeatedly allocate a new
HTTP parser. Thus this bug affects _all_ deployments of
Rainbows! and Zbatery. These servers allocate a new parser for
every client connection.
I misread the Data_Make_Struct/Data_Wrap_Struct documentation
and ended up passing NULL as the "free" argument instead of -1,
causing the memory to never be freed.
From README.EXT in the MRI source which I misread:
> The free argument is the function to free the pointer
> allocation. If this is -1, the pointer will be just freed.
> The functions mark and free will be called from garbage
> collector.
|
|
* maint:
unicorn 0.8.4
http_response: pass through unknown status codes
unicorn 0.8.3
app/exec_cgi: fix 1.9 compatibility
fix tests to run correctly under 1.9.2preview1
Remove core Tempfile dependency (1.9.2-preview1 compat)
|
|
This release includes small changes for things allowed by Rack
1.1. It is also now easier to detect if daemonized process
fails to start. Manpages received some minor updates as well.
Rack 1.1 allowed us to make the following environment changes:
* "rack.logger" is now set to the "logger" specified in
the Unicorn config file. This defaults to a Logger
instance pointing to $stderr.
* "rack.version" is now at [1,1]. Unicorn remains
compatible with previous Rack versions if your app
depends on it.
While only specified since Rack 1.1, Unicorn has always exposed
"rack.input" in binary mode (and has ridiculous integration
tests that go outside of Ruby to prove it!).
|
|
* rack-1.1:
http_response: disallow blank, multi-value headers
local.mk.sample: use rack-1.1.0
bump "rack.version" env to [1,1]
set env["rack.logger"] for applications
|
|
The HeaderHash optimizations in Rack 1.1 interact badly with
Rails 2.3.5 (and possibly other frameworks/apps) which set
multi-value "Set-Cookie" headers without relying on the proper
methods provided by Rack::Utils.
While this is an issue with Rails not using properly, there
may be similar apps that make this mistake and Rack::Lint
does not guard against it.
Rack-ML-Ref: <20100105235845.GB3377@dcvr.yhbt.net>
|
|
|
|
Rails 2.3.3.1 is ancient
|
|
* ready_pipe:
launcher: no point in sync-ing $stdin
launcher: fix compatibility with other servers
clarify errors when listeners fail to bind
launcher: descriptive error message on startup failure
Avoid leaking ready pipe file descriptor to workers
exit with failure if master dies when daemonized
|
|
|
|
Inspection of the MRI source reveals that IO#sync=true only
appears to only apply for writes. Though it could eventually
make sense to disable read buffering by setting IO#sync=true,
it does not appear to happen.
Of course we never read from $stdin anyways....
|
|
Rainbows! does not yet know about ready_pipe, and will probably
not know about it until Unicorn 0.97.0
|
|
When using multiple listeners, the log messages can be
potentially misleading as to which listener fails to bind:
Before:
INFO -- : unlinking existing socket=/tmp/unicorn.sock
INFO -- : listening on addr=/tmp/unicorn.sock fd=3
unicorn/socket_helper.rb:110:in `initialize': Permission denied - bind(2) (Errno::EACCES)
After:
INFO -- : unlinking existing socket=/tmp/openxdms.sock
INFO -- : listening on addr=/tmp/openxdms.sock fd=3
FATAL -- : error adding listener addr=0.0.0.0:84
unicorn/socket_helper.rb:110:in `initialize': Permission denied - bind(2) (Errno::EACCES)
|
|
When using multiple listeners, the log messages can be
potentially misleading as to which listener fails to bind:
Before:
INFO -- : unlinking existing socket=/tmp/unicorn.sock
INFO -- : listening on addr=/tmp/unicorn.sock fd=3
unicorn/socket_helper.rb:110:in `initialize': Permission denied - bind(2) (Errno::EACCES)
After:
INFO -- : unlinking existing socket=/tmp/openxdms.sock
INFO -- : listening on addr=/tmp/openxdms.sock fd=3
FATAL -- : error adding listener addr=0.0.0.0:84
unicorn/socket_helper.rb:110:in `initialize': Permission denied - bind(2) (Errno::EACCES)
|
|
Rather than erroring out with a non-descript EOFError,
show a warning message telling users to check the logs
instead.
Reported-by: Iñaki Baz Castillo mid=200912281350.44760.ibc@aliax.net
|
|
Otherwise the original spawner process may not notice the close
as it's still being shared by workers. While we're at it, avoid
confusing the original spawner by using readpartial instead of
sysread.
|
|
This behavior change also means our grandparent (launched
from a controlling terminal or script) will wait until
the master process is ready before returning.
Thanks to Iñaki Baz Castillo for the initial implementations
and inspiration.
|
|
This will match what's in Rack the 1.1.0 release.
|
|
working_directory and Worker#user got added over time, so
recommending Dir.chdir and Process::UID.change_privilege
is bad.
|
|
|
|
The HTTP parser now allows (but does not parse) the userinfo
component in the very rare requests that send absoluteURIs.
Thanks to Scott Chacon for reporting and submitting a test case
for this fix.
There are also minor documentation updates and tiny cleanups.
|
|
It should be more compatible and easier to express that they're
overridable to hackers. We keep the lower-case versions around
in case people depend on them.
|
|
|
|
TODO: fix RDoc to ignore *.rbc files
|
|
This is not explicitly specified or listed as an example in in
rfc2616. However, rfc2616 section 3.2.1 defers to rfc2396[1]
for the definition of absolute URIs, so the userinfo component
should be allowable, even if it does not make any sense.
In the real world, previous versions of Mongrel used URI.parse()
and thus allowed userinfo, so we also have precedence to allow
userinfo to be compatible *in case* our interpretation of the
RFCs is incorrect. This change is unfortunately needed because
*occasionally* real clients rely on them.
Reported-by: Scott Chacon
[1] rfc3986 obsoletes rfc2396, but also includes userinfo
|
|
rack.git upstream has it, so it will likely be in Rack 1.1
|
|
Durr....
|
|
No more having bother with a clunky web browser \o/
|
|
Small fixes to our HTTP parser to allows semicolons in PATH_INFO
as allowed by RFC 2396, section 3.3. This is low impact for
existing apps as semicolons are rarely seen in URIs. Our HTTP
parser runs properly under Rubinius 0.13.0 and 1.0.0-rc1 again
(though not yet the rest of the server since we rely heavily on
signals).
Another round of small documentation tweaks and minor cleanups.
|
|
No point in bloating code for an unlikely path (and the memcpy()
vs malloc() tradeoff is debatable...)
|
|
|
|
|
|
preformatted text from shortlog doesn't map well to
most feed readers, it seems.
|
|
|
|
This is allowed according to RFC 2396, section 3.3 and matches
the behavior of URI.parse, as well.
|
|
|
|
No point in repeating ourselves and having to deal with nested
comments + indentation in RDoc. It's also easier for users
to just download the file than to copy-and-paste out of a
typical web browser.
|
|
|
|
These should help make things easier for folks unfamiliar
with nginx setups.
|
|
On heavily loaded machines, this test can take a while,
fortunately our test suite is parallelization-friendly.
|
|
A minor nit, and some folks I know hate needless returns
as MRI does not optimize them away.
|
|
Rubinius appears to have changed semantics and our
rb_str_set_len() emulation doesn't work anymore. Since
rb_str_set_len() is just an optimized version of
rb_str_resize(), we'll just use rb_str_resize() for now
unless we notice something better.
test_http_parser and test_http_parser_ng tests pass under
Rubinius 0.13.0.
|
|
Either people are actually using it or somebody is running a
script to download gems off gemcutter in a loop... I suspect
the former...
|
|
|
|
Nobody really uses or cares for them anyways
|
|
So says the project website and documentation
|
|
Grammar na^H^Hexperts please correct us again if we're wrong.
|
|
|
|
Also re-add RubyForge gem upload for now since some folks
may still want to download from there.
|
|
Configuration files paths given on the command-line are no
longer expanded. This should make configuration reloads
possible when a non-absolute path is specified for --config-file
and Unicorn was deployed to a symlink directories (as with
Capistrano). Since deployments have always been strongly
encouraged to use absolute paths in the config file, this
change does not affect them.
This is our first gem release using gemcutter.
Eric Wong (3):
SIGNALS: HUP + preload_app cannot reload app code
Do not expand paths given on the shell
GNUmakefile: prep release process for gemcutter
|