Added write event handler reset in ngx_http_named_location().

On internal redirects this happens via ngx_http_handler() call, which is
not called on named location redirect.  As a result incorrect write handler
remained (if previously set) and this might cause incorrect behaviour (likely
request hang).

Patch by Yichun Zhang (agentzh).


git-svn-id: svn://svn.nginx.org/nginx/trunk@4615 73f98a42-aea0-e011-b76d-00259023448c
Added r->state reset on fastcgi/scgi/uwsgi request start.

Failing to do so results in problems if 400 or 414 requests are
redirected to fastcgi/scgi/uwsgi upstream, as well as after invalid
headers got from upstream.  This was already fixed for proxy in r3478,
but fastcgi (the only affected protocol at that time) was missed.

Reported by Matthieu Tourne.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4616 73f98a42-aea0-e011-b76d-00259023448c
Fastcgi: fixed padding handling on fixed-size records.

Padding was incorrectly ignored on end request, empty stdout and stderr
fastcgi records.  This resulted in protocol desynchronization if fastcgi
application used these records with padding for some reason.

Reported by Ilia Vinokurov.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4617 73f98a42-aea0-e011-b76d-00259023448c
Rewrite: fixed escaping and possible segfault (ticket #162).

The following code resulted in incorrect escaping of uri and possible
segfault:

    location / {
        rewrite ^(.*) $1?c=$1;
        return 200 "$uri";
    }

If there were arguments in a rewrite's replacement string, and length was
actually calculated (due to duplicate captures as in the example above,
or variables present), the is_args flag was set and incorrectly copied
after length calculation.  This resulted in escaping applied to the uri part
of the replacement, resulting in incorrect escaping.  Additionally, buffer
was allocated without escaping expected, thus this also resulted in buffer
overrun and possible segfault.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4618 73f98a42-aea0-e011-b76d-00259023448c
Accept moderation in case of EMFILE/ENFILE.

In case of EMFILE/ENFILE returned from accept() we disable accept events,
and (in case of no accept mutex used) arm timer to re-enable them later.
With accept mutex we just drop it, and rely on normal accept mutex handling
to re-enable accept events once it's acquired again.

As we now handle errors in question, logging level was changed to "crit"
(instead of "alert" used for unknown errors).

Note: the code might call ngx_enable_accept_events() multiple times if
there are many listen sockets.  The ngx_enable_accept_events() function was
modified to check if connection is already active (via c->read->active) and
skip it then, thus making multiple calls safe.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4619 73f98a42-aea0-e011-b76d-00259023448c
Resolver: protection from duplicate responses.

If we already had CNAME in resolver node (i.e. rn->cnlen and rn->u.cname
set), and got additional response with A record, it resulted in rn->cnlen
set and rn->u.cname overwritten by rn->u.addr (or rn->u.addrs), causing
segmentation fault later in ngx_resolver_free_node() on an attempt to free
overwritten rn->u.cname.  The opposite (i.e. CNAME got after A) might cause
similar problems as well.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4620 73f98a42-aea0-e011-b76d-00259023448c
Fixed possible request hang with filter finalization.

With r->filter_finalize set the ngx_http_finalize_connection() wasn't
called from ngx_http_finalize_request() called with NGX_OK, resulting in
r->main->count not being decremented, thus causing request hang in some
rare situations.

See here for more details:
http://mailman.nginx.org/pipermail/nginx-devel/2012-May/002190.html

Patch by Yichun Zhang (agentzh).


git-svn-id: svn://svn.nginx.org/nginx/trunk@4621 73f98a42-aea0-e011-b76d-00259023448c
Upstream: smooth weighted round-robin balancing.

For edge case weights like { 5, 1, 1 } we now produce { a, a, b, a, c, a, a }
sequence instead of { c, b, a, a, a, a, a } produced previously.

Algorithm is as follows: on each peer selection we increase current_weight
of each eligible peer by its weight, select peer with greatest current_weight
and reduce its current_weight by total number of weight points distributed
among peers.

In case of { 5, 1, 1 } weights this gives the following sequence of
current_weight's:

     a  b  c
     0  0  0  (initial state)

     5  1  1  (a selected)
    -2  1  1

     3  2  2  (a selected)
    -4  2  2

     1  3  3  (b selected)
     1 -4  3

     6 -3  4  (a selected)
    -1 -3  4

     4 -2  5  (c selected)
     4 -2 -2

     9 -1 -1  (a selected)
     2 -1 -1

     7  0  0  (a selected)
     0  0  0

To preserve weight reduction in case of failures the effective_weight
variable was introduced, which usually matches peer's weight, but is
reduced temporarily on peer failures.

This change also fixes loop with backup servers and proxy_next_upstream
http_404 (ticket #47), and skipping alive upstreams in some cases if there
are multiple dead ones (ticket #64).


git-svn-id: svn://svn.nginx.org/nginx/trunk@4622 73f98a42-aea0-e011-b76d-00259023448c
Upstream: fixed ip_hash rebalancing with the "down" flag.

Due to weight being set to 0 for down peers, order of peers after sorting
wasn't the same as without the "down" flag (with down peers at the end),
resulting in client rebalancing for clients on other servers.  The only
rebalancing which should happen after adding "down" to a server is one
for clients on the server.

The problem was introduced in r1377 (which fixed endless loop by setting
weight to 0 for down servers).  The loop is no longer possible with new
smooth algorithm, so preserving original weight is safe.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4623 73f98a42-aea0-e011-b76d-00259023448c
New function ngx_http_get_forwarded_addr() to look up real client address.

On input it takes an original address, string in the X-Forwarded-For format
and its length, list of trusted proxies, and a flag indicating to perform
the recursive search.  On output it returns NGX_OK and the "deepest" valid
address in a chain, or NGX_DECLINED.  It supports AF_INET and AF_INET6.
Additionally, original address and/or proxy may be specified as AF_UNIX.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4624 73f98a42-aea0-e011-b76d-00259023448c
realip: chains of trusted proxies and IPv6 support.

The module now supports recursive search of client address through
the chain of trusted proxies, controlled by the "real_ip_recursive"
directive (closes #2).  It also gets full IPv6 support (closes #44)
and canonical value of the $client_addr variable on address change.

Example:
    real_ip_header X-Forwarded-For;
    set_real_ip_from 127.0.0.0/8;
    set_real_ip_from ::1;
    set_real_ip_from unix:;
    real_ip_recursive on;


git-svn-id: svn://svn.nginx.org/nginx/trunk@4625 73f98a42-aea0-e011-b76d-00259023448c
Fixed compilation warning introduced in r4624.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4626 73f98a42-aea0-e011-b76d-00259023448c
geo: chains of trusted proxies and partial IPv6 support.

The module now supports recursive search of client address through
the chain of trusted proxies, controlled by the "proxy_recursive"
directive in the "geo" block.  It also gets partial IPv6 support:
now proxies may be specified with IPv6 addresses.

Example:
    geo $test {
        ...
        proxy 127.0.0.1;
        proxy ::1;
        proxy_recursive;
    }

There's also a slight change in behavior.  When original client
address (as specified by the "geo" directive) is one of the
trusted proxies, and the value of the X-Forwarded-For request
header cannot not be parsed as a valid address, an original client
address will be used for lookup.  Previously, 255.255.255.255 was
used in this case.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4627 73f98a42-aea0-e011-b76d-00259023448c
geoip: trusted proxies support and partial IPv6 support.

The module now supports recursive search of client address through the
chain of trusted proxies (closes #100), in the same scope as the geo
module.  Proxies are listed by the "geoip_proxy" directive, recursive
search is enabled by the "geoip_proxy_recursive" directive.  IPv6 is
partially supported: proxies may be specified with IPv6 addresses.

Example:
    geoip_country .../GeoIP.dat;
    geoip_proxy 127.0.0.1;
    geoip_proxy ::1;
    geoip_proxy 10.0.0.0/8;
    geoip_proxy_recursive on;


git-svn-id: svn://svn.nginx.org/nginx/trunk@4628 73f98a42-aea0-e011-b76d-00259023448c
Reverted previous attempt to fix complation warning introduced in
r4624 and actually fixed it.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4629 73f98a42-aea0-e011-b76d-00259023448c
Update c->sent in ngx_ssl_send_chain() even if SSL buffer is not used.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4630 73f98a42-aea0-e011-b76d-00259023448c
Fixed win32 build after changes in r4624.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4631 73f98a42-aea0-e011-b76d-00259023448c
Updated OpenSSL used for win32 builds.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4632 73f98a42-aea0-e011-b76d-00259023448c
nginx-1.3.0-RELEASE


git-svn-id: svn://svn.nginx.org/nginx/trunk@4633 73f98a42-aea0-e011-b76d-00259023448c
Version bump.


git-svn-id: svn://svn.nginx.org/nginx/trunk@4635 73f98a42-aea0-e011-b76d-00259023448c