Date | Commit message (Collapse) |
|
Thanks to Michael Guterl for informing us of the issues
and testing the monkey patch.
|
|
This prevents trigger-happy init scripts from reading the pid
file (and thus sending signals) to a not-fully initialized
master process to handle them.
This does NOT fix anything if other processes are sending
signals prematurely without relying on the presence of the pid
file. It's not possible to prevent all cases of this in one
process, even in a purely C application, so we won't bother
trying.
We continue to always defer signal handling to the main loop
anyways, and signals sent to the master process will be
deferred/ignored until Unicorn::HttpServer#join is run.
|
|
This constant hasn't been in active use in our Ruby code for
ages now. All HTTP header constraints are defined in the
C/Ragel HTTP parser and we have tests for them, so there's
no need to repeat ourselves.
|
|
There may be some large-ish internal changes for 0.97.0
|
|
|
|
|
|
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.
|