<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/http, branch release-1.13.8</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Retain CAP_NET_RAW capability for transparent proxying.</title>
<updated>2017-12-13T17:40:53+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-12-13T17:40:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=752f66bf7d70fae2bf05fbf5941ff4be52b2b9a5'/>
<id>752f66bf7d70fae2bf05fbf5941ff4be52b2b9a5</id>
<content type='text'>
The capability is retained automatically in unprivileged worker processes after
changing UID if transparent proxying is enabled at least once in nginx
configuration.

The feature is only available in Linux.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The capability is retained automatically in unprivileged worker processes after
changing UID if transparent proxying is enabled at least once in nginx
configuration.

The feature is only available in Linux.
</pre>
</div>
</content>
</entry>
<entry>
<title>Proxy: escape explicit space in URI in default cache key.</title>
<updated>2017-11-20T17:50:35+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-11-20T17:50:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=6754a404669b527340dd74270289da6adfc6302f'/>
<id>6754a404669b527340dd74270289da6adfc6302f</id>
<content type='text'>
If the flag space_in_uri is set, the URI in HTTP upstream request is escaped to
convert space to %20.  However this flag is not checked while creating the
default cache key.  This leads to different cache keys for requests
'/foo bar' and '/foo%20bar', while the upstream requests are identical.

Additionally, the change fixes background cache updates when the client URI
contains unescaped space.  Default cache key in a subrequest is always based on
escaped URI, while the main request may not escape it.  As a result, background
cache update subrequest may update a different cache entry.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the flag space_in_uri is set, the URI in HTTP upstream request is escaped to
convert space to %20.  However this flag is not checked while creating the
default cache key.  This leads to different cache keys for requests
'/foo bar' and '/foo%20bar', while the upstream requests are identical.

Additionally, the change fixes background cache updates when the client URI
contains unescaped space.  Default cache key in a subrequest is always based on
escaped URI, while the main request may not escape it.  As a result, background
cache update subrequest may update a different cache entry.
</pre>
</div>
</content>
</entry>
<entry>
<title>Inherit valid_unparsed_uri in cloned subrequests (ticket #1430).</title>
<updated>2017-11-20T18:11:19+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-11-20T18:11:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=891908cd0cdf72fca7d4b3de4a8a6fa3602e5cf7'/>
<id>891908cd0cdf72fca7d4b3de4a8a6fa3602e5cf7</id>
<content type='text'>
Inheriting this flag will make the cloned subrequest behave consistently with
the parent.  Specifically, the upstream HTTP request and cache key created by
the proxy module may depend directly on unparsed_uri if valid_unparsed_uri flag
is set.  Previously, the flag was zero for cloned requests, which could make
background update proxy a request different than its parent and cache the result
with a different key.  For example, if client URI contained the escaped slash
character %2F, it was used as is by the proxy module in the main request, but
was unescaped in the subrequests.

Similar problems exist in the slice module.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Inheriting this flag will make the cloned subrequest behave consistently with
the parent.  Specifically, the upstream HTTP request and cache key created by
the proxy module may depend directly on unparsed_uri if valid_unparsed_uri flag
is set.  Previously, the flag was zero for cloned requests, which could make
background update proxy a request different than its parent and cache the result
with a different key.  For example, if client URI contained the escaped slash
character %2F, it was used as is by the proxy module in the main request, but
was unescaped in the subrequests.

Similar problems exist in the slice module.
</pre>
</div>
</content>
</entry>
<entry>
<title>Proxy: simplified conditions of using unparsed uri.</title>
<updated>2017-11-20T10:47:17+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-11-20T10:47:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=de11c2ad09286fe728b357a41543f3ba219f8986'/>
<id>de11c2ad09286fe728b357a41543f3ba219f8986</id>
<content type='text'>
Previously, the unparsed uri was explicitly allowed to be used only by the main
request.  However the valid_unparsed_uri flag is nonzero only in the main
request, which makes the main request check pointless.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, the unparsed uri was explicitly allowed to be used only by the main
request.  However the valid_unparsed_uri flag is nonzero only in the main
request, which makes the main request check pointless.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream: flush low-level buffers on write retry.</title>
<updated>2017-12-01T23:59:14+00:00</updated>
<author>
<name>Patryk Lesiewicz</name>
<email>patryk@google.com</email>
</author>
<published>2017-12-01T23:59:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=7b3f187bc6700a85b9cde04c063de59f4690b10c'/>
<id>7b3f187bc6700a85b9cde04c063de59f4690b10c</id>
<content type='text'>
If the data to write is bigger than what the socket can send, and the
reminder is smaller than NGX_SSL_BUFSIZE, then SSL_write() fails with
SSL_ERROR_WANT_WRITE. The reminder of payload however is successfully
copied to the low-level buffer and all the output chain buffers are
flushed. This means that retry logic doesn't work because
ngx_http_upstream_process_non_buffered_request() checks only if there's
anything in the output chain buffers and ignores the fact that something
may be buffered in low-level parts of the stack.

Signed-off-by: Patryk Lesiewicz &lt;patryk@google.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If the data to write is bigger than what the socket can send, and the
reminder is smaller than NGX_SSL_BUFSIZE, then SSL_write() fails with
SSL_ERROR_WANT_WRITE. The reminder of payload however is successfully
copied to the low-level buffer and all the output chain buffers are
flushed. This means that retry logic doesn't work because
ngx_http_upstream_process_non_buffered_request() checks only if there's
anything in the output chain buffers and ignores the fact that something
may be buffered in low-level parts of the stack.

Signed-off-by: Patryk Lesiewicz &lt;patryk@google.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream keepalive: clean read delayed flag in stored connections.</title>
<updated>2017-11-28T11:00:00+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-11-28T11:00:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=e13268714fa3f57adbc7c3891db86b025d79eaf4'/>
<id>e13268714fa3f57adbc7c3891db86b025d79eaf4</id>
<content type='text'>
If a connection with the read delayed flag set was stored in the keepalive
cache, and after picking it from the cache a read timer was set on that
connection, this timer was considered a delay timer rather than a socket read
event timer as expected.  The latter timeout is usually much longer than the
former, which caused a significant delay in request processing.

The issue manifested itself with proxy_limit_rate and upstream keepalive
enabled and exists since 973ee2276300 (1.7.7) when proxy_limit_rate was
introduced.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If a connection with the read delayed flag set was stored in the keepalive
cache, and after picking it from the cache a read timer was set on that
connection, this timer was considered a delay timer rather than a socket read
event timer as expected.  The latter timeout is usually much longer than the
former, which caused a significant delay in request processing.

The issue manifested itself with proxy_limit_rate and upstream keepalive
enabled and exists since 973ee2276300 (1.7.7) when proxy_limit_rate was
introduced.
</pre>
</div>
</content>
</entry>
<entry>
<title>Autoindex: discard request body (ticket #1439).</title>
<updated>2017-12-04T14:30:02+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-12-04T14:30:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=53e5a746bff6860607d0afced9de9854ad62c50f'/>
<id>53e5a746bff6860607d0afced9de9854ad62c50f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed worker_shutdown_timeout in various cases.</title>
<updated>2017-11-20T13:31:07+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-11-20T13:31:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=b32cb6b61079d2eff69c89e0e718a79258507717'/>
<id>b32cb6b61079d2eff69c89e0e718a79258507717</id>
<content type='text'>
The ngx_http_upstream_process_upgraded() did not handle c-&gt;close request,
and upgraded connections do not use the write filter.  As a result,
worker_shutdown_timeout did not affect upgraded connections (ticket #1419).
Fix is to handle c-&gt;close in the ngx_http_request_handler() function, thus
covering most of the possible cases in http handling.

Additionally, mail proxying did not handle neither c-&gt;close nor c-&gt;error,
and thus worker_shutdown_timeout did not work for mail connections.  Fix is
to add c-&gt;close handling to ngx_mail_proxy_handler().

Also, added explicit handling of c-&gt;close to stream proxy,
ngx_stream_proxy_process_connection().  This improves worker_shutdown_timeout
handling in stream, it will no longer wait for some data being transferred
in a connection before closing it, and will also provide appropriate
logging at the "info" level.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ngx_http_upstream_process_upgraded() did not handle c-&gt;close request,
and upgraded connections do not use the write filter.  As a result,
worker_shutdown_timeout did not affect upgraded connections (ticket #1419).
Fix is to handle c-&gt;close in the ngx_http_request_handler() function, thus
covering most of the possible cases in http handling.

Additionally, mail proxying did not handle neither c-&gt;close nor c-&gt;error,
and thus worker_shutdown_timeout did not work for mail connections.  Fix is
to add c-&gt;close handling to ngx_mail_proxy_handler().

Also, added explicit handling of c-&gt;close to stream proxy,
ngx_stream_proxy_process_connection().  This improves worker_shutdown_timeout
handling in stream, it will no longer wait for some data being transferred
in a connection before closing it, and will also provide appropriate
logging at the "info" level.
</pre>
</div>
</content>
</entry>
<entry>
<title>Gzip: support for a zlib variant from Intel.</title>
<updated>2017-11-18T01:03:27+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-11-18T01:03:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f1c4853ea1a981073b067cd1356febd08b86f898'/>
<id>f1c4853ea1a981073b067cd1356febd08b86f898</id>
<content type='text'>
A zlib variant from Intel as available from https://github.com/jtkukunas/zlib
uses 64K hash instead of scaling it from the specified memory level, and
also uses 16-byte padding in one of the window-sized memory buffers, and can
force window bits to 13 if compression level is set to 1 and appropriate
compile options are used.  As a result, nginx complained with "gzip filter
failed to use preallocated memory" alerts.

This change improves deflate_state allocation detection by testing that
items is 1 (deflate_state is the only allocation where items is 1).
Additionally, on first failure to use preallocated memory we now assume
that we are working with the Intel's modified zlib, and switch to using
appropriate preallocations.  If this does not help, we complain with the
usual alerts.

Previous version of this patch was published at
http://mailman.nginx.org/pipermail/nginx/2014-July/044568.html.
The zlib variant in question is used by default in ClearLinux from Intel,
see http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060421.html,
http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060544.html.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A zlib variant from Intel as available from https://github.com/jtkukunas/zlib
uses 64K hash instead of scaling it from the specified memory level, and
also uses 16-byte padding in one of the window-sized memory buffers, and can
force window bits to 13 if compression level is set to 1 and appropriate
compile options are used.  As a result, nginx complained with "gzip filter
failed to use preallocated memory" alerts.

This change improves deflate_state allocation detection by testing that
items is 1 (deflate_state is the only allocation where items is 1).
Additionally, on first failure to use preallocated memory we now assume
that we are working with the Intel's modified zlib, and switch to using
appropriate preallocations.  If this does not help, we complain with the
usual alerts.

Previous version of this patch was published at
http://mailman.nginx.org/pipermail/nginx/2014-July/044568.html.
The zlib variant in question is used by default in ClearLinux from Intel,
see http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060421.html,
http://mailman.nginx.org/pipermail/nginx-ru/2017-November/060544.html.
</pre>
</div>
</content>
</entry>
<entry>
<title>Xslt: fixed parameters parsing (ticket #1416).</title>
<updated>2017-11-16T10:20:47+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2017-11-16T10:20:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=cdbdbbd8423ab96c89c034d879b16b1a931eb38a'/>
<id>cdbdbbd8423ab96c89c034d879b16b1a931eb38a</id>
<content type='text'>
If parameters were specified in xslt_stylesheet without variables,
any request except the first would cause an internal server error.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If parameters were specified in xslt_stylesheet without variables,
any request except the first would cause an internal server error.
</pre>
</div>
</content>
</entry>
</feed>
