Date | Commit message (Collapse) |
|
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.
|
|
Just in case we have people that don't use DNS, we can support
folks who enter ugly IPv6 addresses...
IPv6 uses brackets around the address to avoid confusing
the colons used in the address with the colon used to denote
the TCP port number in URIs.
|
|
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.
|
|
The client may not get a proper response with TCP_CORK enabled
|
|
Reported by: ghazel@gmail.com
ref: <AANLkTimTpPATTpkoD2EYA2eM1+5OzCN=WxnCygQmJdhn@mail.gmail.com>
|
|
This feature is in nginx 0.7.x and 0.8.x and optimized
better than the "if" directive in nginx.conf
ref: http://wiki.nginx.org/Pitfalls
ref: http://wiki.nginx.org/IfIsEvil
|
|
There's no need to use listen unless you use non-default port or
can enable "deferred" or "httpready" (which you usually want).
|
|
Ruby 1.9.1, Sinatra 0.3.x, and Rails 2.3.2 are not in
common use anymore (at least we don't think).
|
|
Reported by Alexey Bondar.
|
|
bogomips.org is slimming down and losing URL weight :)
|
|
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.
(cherry picked from commit 6cca8e61c66c1c2a8ebe260813fa83e44530a768)
|
|
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.
|
|
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.
|
|
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
(cherry picked from commit b72a86f66c722d56a6d77ed1d2779ace6ad103ed)
Conflicts:
lib/unicorn/http_server.rb
test/unit/test_response.rb
|
|
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.
|
|
We use this in Rainbows! to disable keepalive in certain
configurations.
|
|
We do not link against any external libraries
|
|
Oops!
|
|
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)
|
|
Oops
|
|
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.
|
|
We need to preserve our internal flags and only clear them on
HttpParser#parse. This allows the async concurrency models in
Rainbows! to work properly.
|
|
The kgio 2.x series will maintain API compatibility
until 3.x, so it's safe to use any 2.x release.
|
|
Oops
|
|
wrongdoc factors out a bunch of common code from this
project into its own and removes JavaScript from RDoc
to boot.
|
|
Disabling TeeInput is possible now, so the filesystem
is no longer a bottleneck :>
|
|
It's more useful this way
|
|
Hopefully this gets more people reading our source.
|
|
This is the most important part of Unicorn documentation
for end users.
|
|
More config bloat, sadly this is necessary for Rainbows! :<
|
|
Evil clients may be exposed to the Unicorn parser via
Rainbows!, so we'll allow people to turn off blindly
trusting certain X-Forwarded* headers for "rack.url_scheme"
and rely on middleware to handle it.
|
|
rack.url_scheme handling and SERVER_{NAME,PORT} handling
each deserve their own functions.
|
|
The first value of X-Forwarded-Proto in rack.url_scheme should
be used as it can be chained. This header can be set multiple
times via different proxies in the chain, but consider the first
one to be valid.
Additionally, respect X-Forwarded-SSL as it may be passed with
the "on" flag instead of X-Forwarded-Proto.
ref: rack commit 85ca454e6143a3081d90e4546ccad602a4c3ad2e
and 35bb5ba6746b5d346de9202c004cc926039650c7
|
|
This limits the number of keepalive requests of a single
connection to prevent a single client from monopolizing server
resources. On multi-process servers (e.g. Rainbows!) with many
keepalive clients per worker process, this can force a client to
reconnect and increase its chances of being accepted on a
less-busy worker process.
This directive is named after the nginx directive which
is identical in function.
|