<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/http, branch release-1.0.7</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Merging r4086, r4087, r4088, r4090, r4094, r4095, r4096, r4097, r4099, r4100,</title>
<updated>2011-09-30T15:13:47+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T15:13:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9855e45c2c7b807c2b1e53ee35ef4fac2ac2f02b'/>
<id>9855e45c2c7b807c2b1e53ee35ef4fac2ac2f02b</id>
<content type='text'>
r4106, r4107, r4108, r4113, r4156, r4157:

*) ngx_http_mp4_module.
*) "video/mp4" mime type added.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r4106, r4107, r4108, r4113, r4156, r4157:

*) ngx_http_mp4_module.
*) "video/mp4" mime type added.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r3986, r4006, r4007, r4073:</title>
<updated>2011-09-30T14:36:19+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T14:36:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f358278a69d049dc7b5d034005837d08435627ea'/>
<id>f358278a69d049dc7b5d034005837d08435627ea</id>
<content type='text'>
Request body related fixes:

*) Always set timer in discard body handler, this fixes the cases
when request for static file is redirected by error_page to an SSI page.

*) Correctly set body if it's preread and there are extra data.

Previously all available data was used as body, resulting in garbage after
real body e.g. in case of pipelined requests.  Make sure to use only as many
bytes as request's Content-Length specifies.

*) Fix body with request_body_in_single_buf.

If there were preread data and request body was big enough first part
of the request body was duplicated.

See report here:
http://mailman.nginx.org/pipermail/nginx/2011-July/027756.html

*) Bugfix: read event was not blocked after reading body.

Read event should be blocked after reading body, else undefined behaviour
might occur on additional client activity.  This fixes segmentation faults
observed with proxy_ignore_client_abort set.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Request body related fixes:

*) Always set timer in discard body handler, this fixes the cases
when request for static file is redirected by error_page to an SSI page.

*) Correctly set body if it's preread and there are extra data.

Previously all available data was used as body, resulting in garbage after
real body e.g. in case of pipelined requests.  Make sure to use only as many
bytes as request's Content-Length specifies.

*) Fix body with request_body_in_single_buf.

If there were preread data and request body was big enough first part
of the request body was duplicated.

See report here:
http://mailman.nginx.org/pipermail/nginx/2011-July/027756.html

*) Bugfix: read event was not blocked after reading body.

Read event should be blocked after reading body, else undefined behaviour
might occur on additional client activity.  This fixes segmentation faults
observed with proxy_ignore_client_abort set.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r4011, r4012, r4136:</title>
<updated>2011-09-30T14:30:01+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T14:30:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=0b0360a582b95a15821656663ee00f606d6d5611'/>
<id>0b0360a582b95a15821656663ee00f606d6d5611</id>
<content type='text'>
Proxy related fixes:

*) Fixing cpu hog with all upstream servers marked "down".

The following configuration causes nginx to hog cpu due to infinite loop
in ngx_http_upstream_get_peer():

    upstream backend {
        server 127.0.0.1:8080 down;
        server 127.0.0.1:8080 down;
    }

    server {
       ...
       location / {
           proxy_pass http://backend;
       }
    }

Make sure we don't loop infinitely in ngx_http_upstream_get_peer() but stop
after resetting peer weights once.

Return 0 if we are stuck.  This is guaranteed to work as peer 0 always exists,
and eventually ngx_http_upstream_get_round_robin_peer() will do the right
thing falling back to backup servers or returning NGX_BUSY.

*) Upstream: properly allocate memory for tried flags.

Previous allocation only took into account number of non-backup servers, and
this caused memory corruption with many backup servers.

See report here:
http://mailman.nginx.org/pipermail/nginx/2011-May/026531.html

*) Fix of cpu hog in event pipe.

If client closed connection in ngx_event_pipe_write_to_downstream(), buffers
in the "out" chain were lost.  This caused cpu hog if all available buffers
were in the "out" chain.  Fix is to call ngx_chain_update_chains() before
checking return code of output filter to avoid loosing buffers in the "out"
chain.

Note that this situation (all available buffers in the "out" chain) isn't
normal, it should be prevented by busy buffers limit.  Though right now it
may happen with complex protocols like fastcgi.  This should be addressed
separately.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Proxy related fixes:

*) Fixing cpu hog with all upstream servers marked "down".

The following configuration causes nginx to hog cpu due to infinite loop
in ngx_http_upstream_get_peer():

    upstream backend {
        server 127.0.0.1:8080 down;
        server 127.0.0.1:8080 down;
    }

    server {
       ...
       location / {
           proxy_pass http://backend;
       }
    }

Make sure we don't loop infinitely in ngx_http_upstream_get_peer() but stop
after resetting peer weights once.

Return 0 if we are stuck.  This is guaranteed to work as peer 0 always exists,
and eventually ngx_http_upstream_get_round_robin_peer() will do the right
thing falling back to backup servers or returning NGX_BUSY.

*) Upstream: properly allocate memory for tried flags.

Previous allocation only took into account number of non-backup servers, and
this caused memory corruption with many backup servers.

See report here:
http://mailman.nginx.org/pipermail/nginx/2011-May/026531.html

*) Fix of cpu hog in event pipe.

If client closed connection in ngx_event_pipe_write_to_downstream(), buffers
in the "out" chain were lost.  This caused cpu hog if all available buffers
were in the "out" chain.  Fix is to call ngx_chain_update_chains() before
checking return code of output filter to avoid loosing buffers in the "out"
chain.

Note that this situation (all available buffers in the "out" chain) isn't
normal, it should be prevented by busy buffers limit.  Though right now it
may happen with complex protocols like fastcgi.  This should be addressed
separately.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r4114, r4129:</title>
<updated>2011-09-30T14:20:52+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T14:20:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=893049ef20562e264552b7878ce4add7139589e8'/>
<id>893049ef20562e264552b7878ce4add7139589e8</id>
<content type='text'>
Buffers reuse in chunked filter.

There were 2 buffers allocated on each buffer chain sent through chunked
filter (one buffer for chunk size, another one for trailing CRLF, about
120 bytes in total on 32-bit platforms).  This resulted in large memory
consumption with long-lived requests sending many buffer chains.  Usual
example of problematic scenario is streaming though proxy with
proxy_buffering set to off.

Introduced buffers reuse reduces memory consumption in the above problematic
scenario.

See here for initial report:
http://mailman.nginx.org/pipermail/nginx/2010-April/019814.html
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Buffers reuse in chunked filter.

There were 2 buffers allocated on each buffer chain sent through chunked
filter (one buffer for chunk size, another one for trailing CRLF, about
120 bytes in total on 32-bit platforms).  This resulted in large memory
consumption with long-lived requests sending many buffer chains.  Usual
example of problematic scenario is streaming though proxy with
proxy_buffering set to off.

Introduced buffers reuse reduces memory consumption in the above problematic
scenario.

See here for initial report:
http://mailman.nginx.org/pipermail/nginx/2010-April/019814.html
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r4137:</title>
<updated>2011-09-30T14:18:58+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T14:18:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=b8b0479e1cd8956236be4d2733f2e57f4d76b4d7'/>
<id>b8b0479e1cd8956236be4d2733f2e57f4d76b4d7</id>
<content type='text'>
Fixed loss of chain links in fastcgi module.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fixed loss of chain links in fastcgi module.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r4036, r4055, r4056, r4057, r4058, r4059, r4060, r4061, r4062, r4063,</title>
<updated>2011-09-30T14:06:08+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T14:06:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=0b2b252cfbafe2744aa84953729105c8e7c1dc61'/>
<id>0b2b252cfbafe2744aa84953729105c8e7c1dc61</id>
<content type='text'>
r4064:

Ranges related fixes:

The "max_ranges" directive.
"max_ranges 0" disables ranges support at all,
"max_ranges 1" allows the single range, etc.
By default number of ranges is unlimited, to be precise, 2^31-1.

If client requests more ranges than "max_ranges" permits,
nginx disables ranges and returns just the source response.

If total size of all ranges is greater than source response size,
then nginx disables ranges and returns just the source response.
This fix should not affect well-behaving applications but will defeat
DoS attempts exploiting malicious byte ranges.

Now unsatisfiable ranges are processed according to RFC 2616.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
r4064:

Ranges related fixes:

The "max_ranges" directive.
"max_ranges 0" disables ranges support at all,
"max_ranges 1" allows the single range, etc.
By default number of ranges is unlimited, to be precise, 2^31-1.

If client requests more ranges than "max_ranges" permits,
nginx disables ranges and returns just the source response.

If total size of all ranges is greater than source response size,
then nginx disables ranges and returns just the source response.
This fix should not affect well-behaving applications but will defeat
DoS attempts exploiting malicious byte ranges.

Now unsatisfiable ranges are processed according to RFC 2616.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r4010, r4065:</title>
<updated>2011-09-30T13:42:59+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T13:42:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=86553d2e0a955c97846e621fb62a4d3550982ab1'/>
<id>86553d2e0a955c97846e621fb62a4d3550982ab1</id>
<content type='text'>
SSL related fixes:

*) Fixing proxy_set_body and proxy_pass_request_body with SSL.

Flush flag wasn't set in constructed buffer and this prevented any data
from being actually sent to upstream due to SSL buffering.  Make sure
we always set flush in the last buffer we are going to sent.

See here for report:
http://nginx.org/pipermail/nginx-ru/2011-June/041552.html

*) Proper SSL shutdown handling.

If connection has unsent alerts, SSL_shutdown() tries to send them even
if SSL_set_shutdown(SSL_RECEIVED_SHUTDOWN|SSL_SENT_SHUTDOWN) was used.
This can be prevented by SSL_set_quiet_shutdown().  SSL_set_shutdown()
is required nevertheless to preserve session.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
SSL related fixes:

*) Fixing proxy_set_body and proxy_pass_request_body with SSL.

Flush flag wasn't set in constructed buffer and this prevented any data
from being actually sent to upstream due to SSL buffering.  Make sure
we always set flush in the last buffer we are going to sent.

See here for report:
http://nginx.org/pipermail/nginx-ru/2011-June/041552.html

*) Proper SSL shutdown handling.

If connection has unsent alerts, SSL_shutdown() tries to send them even
if SSL_set_shutdown(SSL_RECEIVED_SHUTDOWN|SSL_SENT_SHUTDOWN) was used.
This can be prevented by SSL_set_quiet_shutdown().  SSL_set_shutdown()
is required nevertheless to preserve session.
</pre>
</div>
</content>
</entry>
<entry>
<title>Merging r3933, r4154:</title>
<updated>2011-09-30T13:36:33+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T13:36:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=4918eb4407b5edf62fe2add6aa140052e2d59e3d'/>
<id>4918eb4407b5edf62fe2add6aa140052e2d59e3d</id>
<content type='text'>
A new fix for the case when ssl_session_cache defined, but ssl is not
enabled in any server. The previous r1033 does not help when unused zone
becomes used after reconfiguration, so it is backed out.

The initial thought was to make SSL modules independed from SSL implementation
and to keep OpenSSL code dependance as much as in separate files.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A new fix for the case when ssl_session_cache defined, but ssl is not
enabled in any server. The previous r1033 does not help when unused zone
becomes used after reconfiguration, so it is backed out.

The initial thought was to make SSL modules independed from SSL implementation
and to keep OpenSSL code dependance as much as in separate files.
</pre>
</div>
</content>
</entry>
<entry>
<title>Version bump.</title>
<updated>2011-09-30T13:24:49+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-09-30T13:24:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=05596e58393f07e7100b551c73ca1fdbc24aa338'/>
<id>05596e58393f07e7100b551c73ca1fdbc24aa338</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge of r4016:</title>
<updated>2011-08-29T14:13:46+00:00</updated>
<author>
<name>Igor Sysoev</name>
<email>igor@sysoev.ru</email>
</author>
<published>2011-08-29T14:13:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=5c4e11692d0479868b27d1c4408993c335f23506'/>
<id>5c4e11692d0479868b27d1c4408993c335f23506</id>
<content type='text'>
Fix ignored headers handling in fastcgi/scgi/uwsgi.

The bug had appeared in r3561 (fastcgi), r3638 (scgi), r3567 (uwsgi).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix ignored headers handling in fastcgi/scgi/uwsgi.

The bug had appeared in r3561 (fastcgi), r3638 (scgi), r3567 (uwsgi).
</pre>
</div>
</content>
</entry>
</feed>
