You can listen on 0.0.0.0, but trying to connect to it doesn't work well on OpenBSD. Acked-by: Eric Wong <firstname.lastname@example.org>
There's no practical difference between a timeout of 30 days and 68 years from an HTTP server standpoint. POSIX limits us to 31 days, actually, but there could be rounding error with floats used in Ruby time calculations and there's no real difference between 30 and 31 days, either... Thanks to Jeremy Evans for pointing out large values will throw EINVAL (on select(2) under OpenBSD with Ruby 1.9.3 and RangeError on older Rubies.
Since unicorn is designed to be deployed behind nginx (or similar), X-Forwarded-* headers are common and Rack applications may blindly trust spoofed X-Forwarded-* headers. UnXF provides a central place for managing that trust by using rpatricia.
The old comment was confusing. We only zero the tick counter when forking because application loading can take a long time. Otherwise, it's always updated. ref: http://mid.gmane.org/20110908191352.GA25251@dcvr.yhbt.net
There is no need to keep extra hashes or Proc objects around in the heap.
Existing license terms (Ruby-specific) and GPLv2 remain in place, but GPLv3 is preferred as it helps with distribution of AGPLv3 code and is explicitly compatible with Apache License (v2.0). Many more reasons are documented by the FSF: https://www.gnu.org/licenses/quick-guide-gplv3.html http://gplv3.fsf.org/rms-why.html ref: http://thread.gmane.org/gmane.comp.lang.ruby.unicorn.general/933
The last-resort timeout mechanism was inaccurate and often delayed in activation since the 2.0.0 release. It is now fixed and remains power-efficient in idle situations, especially with the wakeup reduction in MRI 1.9.3+. There is also a new document on application timeouts intended to discourage the reliance on this last-resort mechanism. It is visible on the web at: http://unicorn.bogomips.org/Application_Timeouts.html
* Rack::Chunked and Rack::ContentLength middlewares are loaded by default for RACK_ENV=(development|deployment) users to match Rack::Server behavior. As before, use RACK_ENV=none if you want fine-grained control of your middleware. This should also help users of Rainbows! and Zbatery. * CTL characters are now rejected from HTTP header values * Exception messages are now filtered for [:cntrl:] characters since application/middleware authors may forget to do so * Workers will now terminate properly if a SIGQUIT/SIGTERM/SIGINT is received while during worker process initialization. * close-on-exec is explicitly disabled to future-proof against Ruby 2.0 changes [ruby-core:38140]
The signal handler from the master is still active and will push the pending signal to SIG_QUEUE if a worker receives a signal immediately after forking.
This is needed to match the behavior of Rack::Server for RACK_ENV=(deployment|development), actually. This won't affect users of other RACK_ENV values. This change has minor performance consequences, so users negatively affected should set RACK_ENV to "none" instead for full control of their middleware stack. This mainly affects Rainbows!/Zbatery users since they have persistent connections and /need/ Content-Length or Transfer-Encoding:chunked headers.
Setting the close-on-exec flag by default and closing non-standard descriptors is proposed for Ruby 1.9.4/2.0.0. Since Unicorn is one of the few apps to rely on FD inheritance across exec(), we need to workaround this by redirecting each listener FD to itself for Kernel#exec. Ruby supports a hash as the final argument to Kernel#exec since at least 1.9.1 (nobody cares for 1.9.0 anymore). This allows users to backport close-on-exec by default patches to older 1.9.x installs without breaking anything. ref: http://redmine.ruby-lang.org/issues/5041
I don't build IPv6 into all my kernels; maybe other testers do not, either.
Thanks to Tatsuya Ono on the unicorn mailing list.
Future versions of Ruby may change this from the default *nix behavior, so we need to explicitly allow FD passing via exec(). ref: http://redmine.ruby-lang.org/issues/5041
RFC 2616 doesn't appear to allow most CTL bytes even though Mongrel always did. Rack::Lint disallows 0..31, too, though we allow "\t" (HT, 09) since it's LWS and allowed by RFC 2616.
This release fixes things for users of per-worker "listen" directives in the after_fork hook. Thanks to email@example.com for reporting the bug. The "timeout" configurator directive is now truncated to 0x7ffffffe seconds to prevent overflow when calling IO.select.
The testcase for this was broken, too, so we didn't notice this :< Reported-by: firstname.lastname@example.org on the Rainbows! mailing list, http://mid.gmane.org/BANLkTi=oQXK5Casq9SuGD3edeUrDPvRm3A@mail.gmail.com
IO.select in Ruby can't wait longer than this. This means Unicorn can't support applications that take longer than 68 years to respond :(