<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/stream, 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>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>Upstream hash: reordered peer checks.</title>
<updated>2017-10-05T14:43:05+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-10-05T14:43:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=53d655f89407af017cd193fd4d8d82118c9c2c80'/>
<id>53d655f89407af017cd193fd4d8d82118c9c2c80</id>
<content type='text'>
This slightly reduces cost of selecting a peer if all or almost all peers
failed, see ticket #1030.  There should be no measureable difference with
other workloads.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This slightly reduces cost of selecting a peer if all or almost all peers
failed, see ticket #1030.  There should be no measureable difference with
other workloads.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream hash: limited number of tries in consistent case.</title>
<updated>2017-10-05T14:42:59+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-10-05T14:42:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=a10ec2db91b448029968025d23155e9c383f522d'/>
<id>a10ec2db91b448029968025d23155e9c383f522d</id>
<content type='text'>
While this may result in non-ideal distribution of requests if nginx
won't be able to select a server in a reasonable number of attempts,
this still looks better than severe performance degradation observed
if there is no limit and there are many points configured (ticket #1030).
This is also in line with what we do for other hash balancing methods.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While this may result in non-ideal distribution of requests if nginx
won't be able to select a server in a reasonable number of attempts,
this still looks better than severe performance degradation observed
if there is no limit and there are many points configured (ticket #1030).
This is also in line with what we do for other hash balancing methods.
</pre>
</div>
</content>
</entry>
<entry>
<title>Fixed handling of unix sockets in $binary_remote_addr.</title>
<updated>2017-10-04T18:19:42+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2017-10-04T18:19:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=41d8ea8c8d268555d3cbd8dd2ab32dcc06658209'/>
<id>41d8ea8c8d268555d3cbd8dd2ab32dcc06658209</id>
<content type='text'>
Previously, unix sockets were treated as AF_INET ones, and this may
result in buffer overread on Linux, where unbound unix sockets have
2-byte addresses.

Note that it is not correct to use just sun_path as a binary representation
for unix sockets.  This will result in an empty string for unbound unix
sockets, and thus behaviour of limit_req and limit_conn will change when
switching from $remote_addr to $binary_remote_addr.  As such, normal text
representation is used.

Reported by Stephan Dollberg.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, unix sockets were treated as AF_INET ones, and this may
result in buffer overread on Linux, where unbound unix sockets have
2-byte addresses.

Note that it is not correct to use just sun_path as a binary representation
for unix sockets.  This will result in an empty string for unbound unix
sockets, and thus behaviour of limit_req and limit_conn will change when
switching from $remote_addr to $binary_remote_addr.  As such, normal text
representation is used.

Reported by Stephan Dollberg.
</pre>
</div>
</content>
</entry>
<entry>
<title>Modules compatibility: down flag promoted to a bitmask.</title>
<updated>2017-09-22T19:49:42+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2017-09-22T19:49:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=e7738ce82d1836440fafa9d20dde6c9a28d4ecf4'/>
<id>e7738ce82d1836440fafa9d20dde6c9a28d4ecf4</id>
<content type='text'>
It is to be used as a bitmask with various bits set/reset when appropriate.
63b8b157b776 made a similar change to ngx_http_upstream_rr_peer_t.down and
ngx_stream_upstream_rr_peer_t.down.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is to be used as a bitmask with various bits set/reset when appropriate.
63b8b157b776 made a similar change to ngx_http_upstream_rr_peer_t.down and
ngx_stream_upstream_rr_peer_t.down.
</pre>
</div>
</content>
</entry>
<entry>
<title>Style.</title>
<updated>2017-09-22T15:37:49+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2017-09-22T15:37:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ccd7e1037ef627b8103df9f565e25e3e1795bf8d'/>
<id>ccd7e1037ef627b8103df9f565e25e3e1795bf8d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Do not use the obsolete NGX_SOCKADDRLEN macro.</title>
<updated>2017-09-22T10:10:49+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2017-09-22T10:10:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=0cda728c6f9a7bb789d5e1b9123f6654f408c5e9'/>
<id>0cda728c6f9a7bb789d5e1b9123f6654f408c5e9</id>
<content type='text'>
The change in ac120e797d28 re-used the macro which was made obsolete
in adf25b8d0431.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The change in ac120e797d28 re-used the macro which was made obsolete
in adf25b8d0431.
</pre>
</div>
</content>
</entry>
<entry>
<title>Stream: fixed logging UDP upstream timeout.</title>
<updated>2017-09-12T10:44:04+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-09-12T10:44:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=c36a3c0cba7082f4b4933e90eef986e49e3eea98'/>
<id>c36a3c0cba7082f4b4933e90eef986e49e3eea98</id>
<content type='text'>
Previously, when the first UDP response packet was not received from the
proxied server within proxy_timeout, no error message was logged before
switching to the next upstream.  Additionally, when one of succeeding response
packets was not received within the timeout, the timeout error had low severity
because it was logged as a client connection error as opposed to upstream
connection error.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, when the first UDP response packet was not received from the
proxied server within proxy_timeout, no error message was logged before
switching to the next upstream.  Additionally, when one of succeeding response
packets was not received within the timeout, the timeout error had low severity
because it was logged as a client connection error as opposed to upstream
connection error.
</pre>
</div>
</content>
</entry>
<entry>
<title>Stream: relaxed next upstream condition (ticket #1317).</title>
<updated>2017-09-11T12:32:31+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2017-09-11T12:32:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=15f81e0bbf42d8bc6e70a06800720eb9d927efdd'/>
<id>15f81e0bbf42d8bc6e70a06800720eb9d927efdd</id>
<content type='text'>
When switching to a next upstream, some buffers could be stuck in the middle
of the filter chain.  A condition existed that raised an error when this
happened.  As it turned out, this condition prevented switching to a next
upstream if ssl preread was used with the TCP protocol (see the ticket).

In fact, the condition does not make sense for TCP, since after successful
connection to an upstream switching to another upstream never happens.  As for
UDP, the issue with stuck buffers is unlikely to happen, but is still possible.
Specifically, if a filter delays sending data to upstream.

The condition can be relaxed to only check the "buffered" bitmask of the
upstream connection.  The new condition is simpler and fixes the ticket issue
as well.  Additionally, the upstream_out chain is now reset for UDP prior to
connecting to a new upstream to prevent repeating the client data twice.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When switching to a next upstream, some buffers could be stuck in the middle
of the filter chain.  A condition existed that raised an error when this
happened.  As it turned out, this condition prevented switching to a next
upstream if ssl preread was used with the TCP protocol (see the ticket).

In fact, the condition does not make sense for TCP, since after successful
connection to an upstream switching to another upstream never happens.  As for
UDP, the issue with stuck buffers is unlikely to happen, but is still possible.
Specifically, if a filter delays sending data to upstream.

The condition can be relaxed to only check the "buffered" bitmask of the
upstream connection.  The new condition is simpler and fixes the ticket issue
as well.  Additionally, the upstream_out chain is now reset for UDP prior to
connecting to a new upstream to prevent repeating the client data twice.
</pre>
</div>
</content>
</entry>
</feed>
