<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src, branch release-1.23.0</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Perl: removed unused variables, forgotten in ef6a3a99a81a.</title>
<updated>2022-06-14T06:39:58+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2022-06-14T06:39:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=21506a2f851c9dbff4bee67fe5b6d199c83c799a'/>
<id>21506a2f851c9dbff4bee67fe5b6d199c83c799a</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: make TCP write timer event cancelable.</title>
<updated>2022-06-02T03:17:23+00:00</updated>
<author>
<name>Aleksei Bavshin</name>
<email>a.bavshin@f5.com</email>
</author>
<published>2022-06-02T03:17:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f2fcc03d3aa6f0e0a457a994dbc743b5b63ad035'/>
<id>f2fcc03d3aa6f0e0a457a994dbc743b5b63ad035</id>
<content type='text'>
Similar to 70e65bf8dfd7, the change is made to ensure that the ability to
cancel resolver tasks is fully controlled by the caller.  As mentioned in the
referenced commit, it is safe to make this timer cancelable because resolve
tasks can have their own timeouts that are not cancelable.

The scenario where this may become a problem is a periodic background resolve
task (not tied to a specific request or a client connection), which receives a
response with short TTL, large enough to warrant fallback to a TCP query.
With each event loop wakeup, we either have a previously set write timer
instance or schedule a new one.  The non-cancelable write timer can delay or
block graceful shutdown of a worker even if the ngx_resolver_ctx_t-&gt;cancelable
flag is set by the API user, and there are no other tasks or connections.

We use the resolver API in this way to maintain the list of upstream server
addresses specified with the 'resolve' parameter, and there could be third-party
modules implementing similar logic.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similar to 70e65bf8dfd7, the change is made to ensure that the ability to
cancel resolver tasks is fully controlled by the caller.  As mentioned in the
referenced commit, it is safe to make this timer cancelable because resolve
tasks can have their own timeouts that are not cancelable.

The scenario where this may become a problem is a periodic background resolve
task (not tied to a specific request or a client connection), which receives a
response with short TTL, large enough to warrant fallback to a TCP query.
With each event loop wakeup, we either have a previously set write timer
instance or schedule a new one.  The non-cancelable write timer can delay or
block graceful shutdown of a worker even if the ngx_resolver_ctx_t-&gt;cancelable
flag is set by the API user, and there are no other tasks or connections.

We use the resolver API in this way to maintain the list of upstream server
addresses specified with the 'resolve' parameter, and there could be third-party
modules implementing similar logic.
</pre>
</div>
</content>
</entry>
<entry>
<title>Stream: don't flush empty buffers created for read errors.</title>
<updated>2022-05-23T18:29:44+00:00</updated>
<author>
<name>Aleksei Bavshin</name>
<email>a.bavshin@f5.com</email>
</author>
<published>2022-05-23T18:29:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=d7994be44592f0ce9c240406b13020cdc377a9f0'/>
<id>d7994be44592f0ce9c240406b13020cdc377a9f0</id>
<content type='text'>
When we generate the last_buf buffer for an UDP upstream recv error, it does
not contain any data from the wire. ngx_stream_write_filter attempts to forward
it anyways, which is incorrect (e.g., UDP upstream ECONNREFUSED will be
translated to an empty packet).

This happens because we mark the buffer as both 'flush' and 'last_buf', and
ngx_stream_write_filter has special handling for flush with certain types of
connections (see d127837c714f, 32b0ba4855a6).  The flags are meant to be
mutually exclusive, so the fix is to ensure that flush and last_buf are not set
at the same time.

Reproduction:

stream {
    upstream unreachable {
        server     127.0.0.1:8880;
    }
    server {
        listen     127.0.0.1:8998 udp;
        proxy_pass unreachable;
    }
}

1 0.000000000    127.0.0.1 → 127.0.0.1    UDP 47 45588 → 8998 Len=5
2 0.000166300    127.0.0.1 → 127.0.0.1    UDP 47 51149 → 8880 Len=5
3 0.000172600    127.0.0.1 → 127.0.0.1    ICMP 75 Destination unreachable (Port
unreachable)
4 0.000202400    127.0.0.1 → 127.0.0.1    UDP 42 8998 → 45588 Len=0

Fixes d127837c714f.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When we generate the last_buf buffer for an UDP upstream recv error, it does
not contain any data from the wire. ngx_stream_write_filter attempts to forward
it anyways, which is incorrect (e.g., UDP upstream ECONNREFUSED will be
translated to an empty packet).

This happens because we mark the buffer as both 'flush' and 'last_buf', and
ngx_stream_write_filter has special handling for flush with certain types of
connections (see d127837c714f, 32b0ba4855a6).  The flags are meant to be
mutually exclusive, so the fix is to ensure that flush and last_buf are not set
at the same time.

Reproduction:

stream {
    upstream unreachable {
        server     127.0.0.1:8880;
    }
    server {
        listen     127.0.0.1:8998 udp;
        proxy_pass unreachable;
    }
}

1 0.000000000    127.0.0.1 → 127.0.0.1    UDP 47 45588 → 8998 Len=5
2 0.000166300    127.0.0.1 → 127.0.0.1    UDP 47 51149 → 8880 Len=5
3 0.000172600    127.0.0.1 → 127.0.0.1    ICMP 75 Destination unreachable (Port
unreachable)
4 0.000202400    127.0.0.1 → 127.0.0.1    UDP 42 8998 → 45588 Len=0

Fixes d127837c714f.
</pre>
</div>
</content>
</entry>
<entry>
<title>Mp4: fixed potential overflow in ngx_http_mp4_crop_stts_data().</title>
<updated>2022-06-07T18:58:52+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2022-06-07T18:58:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=80fc2ddf57558ec43b94220ce2d3d88e2e470c75'/>
<id>80fc2ddf57558ec43b94220ce2d3d88e2e470c75</id>
<content type='text'>
Both "count" and "duration" variables are 32-bit, so their product might
potentially overflow.  It is used to reduce 64-bit start_time variable,
and with very large start_time this can result in incorrect seeking.

Found by Coverity (CID 1499904).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Both "count" and "duration" variables are 32-bit, so their product might
potentially overflow.  It is used to reduce 64-bit start_time variable,
and with very large start_time this can result in incorrect seeking.

Found by Coverity (CID 1499904).
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: handling of certificates specified as an empty string.</title>
<updated>2022-06-07T16:08:57+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2022-06-07T16:08:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f08dbefadf083b8546423e35d8d12ba27e46efa8'/>
<id>f08dbefadf083b8546423e35d8d12ba27e46efa8</id>
<content type='text'>
Now, if the directive is given an empty string, such configuration cancels
loading of certificates, in particular, if they would be otherwise inherited
from the previous level.  This restores previous behaviour, before variables
support in certificates was introduced (3ab8e1e2f0f7).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now, if the directive is given an empty string, such configuration cancels
loading of certificates, in particular, if they would be otherwise inherited
from the previous level.  This restores previous behaviour, before variables
support in certificates was introduced (3ab8e1e2f0f7).
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: fixed X-Accel-Expires/Cache-Control/Expires handling.</title>
<updated>2022-06-06T21:07:12+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2022-06-06T21:07:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=8df3ad13c5bb10360221f25ca45ae03dd09e1c3b'/>
<id>8df3ad13c5bb10360221f25ca45ae03dd09e1c3b</id>
<content type='text'>
Previously, if caching was disabled due to Expires in the past, nginx
failed to cache the response even if it was cacheable as per subsequently
parsed Cache-Control header (ticket #964).

Similarly, if caching was disabled due to Expires in the past,
"Cache-Control: no-cache" or "Cache-Control: max-age=0", caching was not
used if it was cacheable as per subsequently parsed X-Accel-Expires header.

Fix is to avoid disabling caching immediately after parsing Expires in
the past or Cache-Control, but rather set flags which are later checked by
ngx_http_upstream_process_headers() (and cleared by "Cache-Control: max-age"
and X-Accel-Expires).

Additionally, now X-Accel-Expires does not prevent parsing of cache control
extensions, notably stale-while-revalidate and stale-if-error.  This
ensures that order of the X-Accel-Expires and Cache-Control headers is not
important.

Prodded by Vadim Fedorenko and Yugo Horie.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, if caching was disabled due to Expires in the past, nginx
failed to cache the response even if it was cacheable as per subsequently
parsed Cache-Control header (ticket #964).

Similarly, if caching was disabled due to Expires in the past,
"Cache-Control: no-cache" or "Cache-Control: max-age=0", caching was not
used if it was cacheable as per subsequently parsed X-Accel-Expires header.

Fix is to avoid disabling caching immediately after parsing Expires in
the past or Cache-Control, but rather set flags which are later checked by
ngx_http_upstream_process_headers() (and cleared by "Cache-Control: max-age"
and X-Accel-Expires).

Additionally, now X-Accel-Expires does not prevent parsing of cache control
extensions, notably stale-while-revalidate and stale-if-error.  This
ensures that order of the X-Accel-Expires and Cache-Control headers is not
important.

Prodded by Vadim Fedorenko and Yugo Horie.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: fixed build without http cache (broken by cd73509f21e2).</title>
<updated>2022-05-30T21:14:11+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2022-05-30T21:14:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=bfc5b35827903a3c543b58e4562db8b62021c164'/>
<id>bfc5b35827903a3c543b58e4562db8b62021c164</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Headers filter: improved memory allocation error handling.</title>
<updated>2022-05-30T18:25:57+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2022-05-30T18:25:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=887d51938ff8ce853e76f746e6a080a18005f6d3'/>
<id>887d51938ff8ce853e76f746e6a080a18005f6d3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Multiple WWW-Authenticate headers with "satisfy any;".</title>
<updated>2022-05-30T18:25:56+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2022-05-30T18:25:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f74e1ea9959f714dd8c284a7811b97815171adc3'/>
<id>f74e1ea9959f714dd8c284a7811b97815171adc3</id>
<content type='text'>
If a module adds multiple WWW-Authenticate headers (ticket #485) to the
response, linked in r-&gt;headers_out.www_authenticate, all headers are now
cleared if another module later allows access.

This change is a nop for standard modules, since the only access module which
can add multiple WWW-Authenticate headers is the auth request module, and
it is checked after other standard access modules.  Though this might
affect some third party access modules.

Note that if a 3rd party module adds a single WWW-Authenticate header
and not yet modified to set the header's next pointer to NULL, attempt to
clear such a header with this change will result in a segmentation fault.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a module adds multiple WWW-Authenticate headers (ticket #485) to the
response, linked in r-&gt;headers_out.www_authenticate, all headers are now
cleared if another module later allows access.

This change is a nop for standard modules, since the only access module which
can add multiple WWW-Authenticate headers is the auth request module, and
it is checked after other standard access modules.  Though this might
affect some third party access modules.

Note that if a 3rd party module adds a single WWW-Authenticate header
and not yet modified to set the header's next pointer to NULL, attempt to
clear such a header with this change will result in a segmentation fault.
</pre>
</div>
</content>
</entry>
<entry>
<title>Auth request: multiple WWW-Authenticate headers (ticket #485).</title>
<updated>2022-05-30T18:25:54+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2022-05-30T18:25:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=911c95bfd3a17632c6f3d8c2f261055520278cc7'/>
<id>911c95bfd3a17632c6f3d8c2f261055520278cc7</id>
<content type='text'>
When using auth_request with an upstream server which returns 401
(Unauthorized), multiple WWW-Authenticate headers from the upstream server
response are now properly copied to the response.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When using auth_request with an upstream server which returns 401
(Unauthorized), multiple WWW-Authenticate headers from the upstream server
response are now properly copied to the response.
</pre>
</div>
</content>
</entry>
</feed>
