<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src, branch release-1.15.3</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Upstream: fixed request chain traversal (ticket #1618).</title>
<updated>2018-08-24T09:19:37+00:00</updated>
<author>
<name>Vladimir Homutov</name>
<email>vl@nginx.com</email>
</author>
<published>2018-08-24T09:19:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=62821f1c99f3bdb79ddbef2386060a6deb192605'/>
<id>62821f1c99f3bdb79ddbef2386060a6deb192605</id>
<content type='text'>
The problem does not manifest itself currently, because in case of
non-buffered reading, chain link created by u-&gt;create_request method
consists of a single element.

Found by PVS-Studio.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The problem does not manifest itself currently, because in case of
non-buffered reading, chain link created by u-&gt;create_request method
consists of a single element.

Found by PVS-Studio.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream keepalive: keepalive_requests directive.</title>
<updated>2018-08-10T18:54:46+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-10T18:54:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=d817ceae729914e7423c4c206165fc244513f021'/>
<id>d817ceae729914e7423c4c206165fc244513f021</id>
<content type='text'>
The directive configures maximum number of requests allowed on
a connection kept in the cache.  Once a connection reaches the number
of requests configured, it is no longer saved to the cache.
The default is 100.

Much like keepalive_requests for client connections, this is mostly
a safeguard to make sure connections are closed periodically and the
memory allocated from the connection pool is freed.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The directive configures maximum number of requests allowed on
a connection kept in the cache.  Once a connection reaches the number
of requests configured, it is no longer saved to the cache.
The default is 100.

Much like keepalive_requests for client connections, this is mostly
a safeguard to make sure connections are closed periodically and the
memory allocated from the connection pool is freed.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream keepalive: keepalive_timeout directive.</title>
<updated>2018-08-10T18:54:23+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-10T18:54:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=7de808990b8e49e2e18c2a013e4cca82a092fdbc'/>
<id>7de808990b8e49e2e18c2a013e4cca82a092fdbc</id>
<content type='text'>
The directive configures maximum time a connection can be kept in the
cache.  By configuring a time which is smaller than the corresponding
timeout on the backend side one can avoid the race between closing
a connection by the backend and nginx trying to use the same connection
to send a request at the same time.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The directive configures maximum time a connection can be kept in the
cache.  By configuring a time which is smaller than the corresponding
timeout on the backend side one can avoid the race between closing
a connection by the backend and nginx trying to use the same connection
to send a request at the same time.
</pre>
</div>
</content>
</entry>
<entry>
<title>Upstream keepalive: comment added.</title>
<updated>2018-08-10T18:54:17+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-10T18:54:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f3d1a925b5e27d8d78fc6da408ccc2f75994939c'/>
<id>f3d1a925b5e27d8d78fc6da408ccc2f75994939c</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>SSL: fixed build with LibreSSL 2.8.0 (ticket #1605).</title>
<updated>2018-08-10T17:49:06+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-10T17:49:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=1b1b632eed84197863b7cc6a00579968362a700b'/>
<id>1b1b632eed84197863b7cc6a00579968362a700b</id>
<content type='text'>
LibreSSL 2.8.0 "added const annotations to many existing APIs from OpenSSL,
making interoperability easier for downstream applications".  This includes
the const change in the SSL_CTX_sess_set_get_cb() callback function (see
9dd43f4ef67e), which breaks compilation.

To fix this, added a condition on how we redefine OPENSSL_VERSION_NUMBER
when working with LibreSSL (see 382fc7069e3a).  With LibreSSL 2.8.0,
we now set OPENSSL_VERSION_NUMBER to 0x1010000fL (OpenSSL 1.1.0), so the
appropriate conditions in the code will use "const" as it happens with
OpenSSL 1.1.0 and later versions.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
LibreSSL 2.8.0 "added const annotations to many existing APIs from OpenSSL,
making interoperability easier for downstream applications".  This includes
the const change in the SSL_CTX_sess_set_get_cb() callback function (see
9dd43f4ef67e), which breaks compilation.

To fix this, added a condition on how we redefine OPENSSL_VERSION_NUMBER
when working with LibreSSL (see 382fc7069e3a).  With LibreSSL 2.8.0,
we now set OPENSSL_VERSION_NUMBER to 0x1010000fL (OpenSSL 1.1.0), so the
appropriate conditions in the code will use "const" as it happens with
OpenSSL 1.1.0 and later versions.
</pre>
</div>
</content>
</entry>
<entry>
<title>HTTP/2: workaround for clients which fail on table size updates.</title>
<updated>2018-08-09T17:12:17+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-09T17:12:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=0d224602e966c431674958dabcaa451c99539352'/>
<id>0d224602e966c431674958dabcaa451c99539352</id>
<content type='text'>
There are clients which cannot handle HPACK's dynamic table size updates
as added in 12cadc4669a7 (1.13.6).  Notably, old versions of OkHttp library
are known to fail on it (ticket #1397).

This change makes it possible to work with such clients by only sending
dynamic table size updates in response to SETTINGS_HEADER_TABLE_SIZE.  As
a downside, clients which do not use SETTINGS_HEADER_TABLE_SIZE will
continue to maintain default 4k table.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There are clients which cannot handle HPACK's dynamic table size updates
as added in 12cadc4669a7 (1.13.6).  Notably, old versions of OkHttp library
are known to fail on it (ticket #1397).

This change makes it possible to work with such clients by only sending
dynamic table size updates in response to SETTINGS_HEADER_TABLE_SIZE.  As
a downside, clients which do not use SETTINGS_HEADER_TABLE_SIZE will
continue to maintain default 4k table.
</pre>
</div>
</content>
</entry>
<entry>
<title>Skipping spaces in configuration files (ticket #1557).</title>
<updated>2018-08-09T09:15:42+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-09T09:15:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=dd8e1e178c1a47d51ce85604a169f9179c15c220'/>
<id>dd8e1e178c1a47d51ce85604a169f9179c15c220</id>
<content type='text'>
Previously, a chunk of spaces larger than NGX_CONF_BUFFER (4096 bytes)
resulted in the "too long parameter" error during parsing such a
configuration.  This was because the code only set start and start_line
on non-whitespace characters, and hence adjacent whitespace characters
were preserved when reading additional data from the configuration file.
Fix is to always move start and start_line if the last character was
a space.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, a chunk of spaces larger than NGX_CONF_BUFFER (4096 bytes)
resulted in the "too long parameter" error during parsing such a
configuration.  This was because the code only set start and start_line
on non-whitespace characters, and hence adjacent whitespace characters
were preserved when reading additional data from the configuration file.
Fix is to always move start and start_line if the last character was
a space.
</pre>
</div>
</content>
</entry>
<entry>
<title>SSL: support for TLSv1.3 early data with BoringSSL.</title>
<updated>2018-08-06T23:16:07+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-06T23:16:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3b1589173f28fccb5816669f3ff4c9ac1e9b573c'/>
<id>3b1589173f28fccb5816669f3ff4c9ac1e9b573c</id>
<content type='text'>
Early data AKA 0-RTT mode is enabled as long as "ssl_early_data on" is
specified in the configuration (default is off).

The $ssl_early_data variable evaluates to "1" if the SSL handshake
isn't yet completed, and can be used to set the Early-Data header as
per draft-ietf-httpbis-replay-04.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Early data AKA 0-RTT mode is enabled as long as "ssl_early_data on" is
specified in the configuration (default is off).

The $ssl_early_data variable evaluates to "1" if the SSL handshake
isn't yet completed, and can be used to set the Early-Data header as
per draft-ietf-httpbis-replay-04.
</pre>
</div>
</content>
</entry>
<entry>
<title>SSL: enabled TLSv1.3 with BoringSSL.</title>
<updated>2018-08-06T23:15:28+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-06T23:15:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9f30fda1c2e24058e91a8c637c0717b32be399da'/>
<id>9f30fda1c2e24058e91a8c637c0717b32be399da</id>
<content type='text'>
BoringSSL currently requires SSL_CTX_set_max_proto_version(TLS1_3_VERSION)
to be able to enable TLS 1.3.  This is because by default max protocol
version is set to TLS 1.2, and the SSL_OP_NO_* options are merely used
as a blacklist within the version range specified using the
SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version()
functions.

With this change, we now call SSL_CTX_set_max_proto_version() with an
explicit maximum version set.  This enables TLS 1.3 with BoringSSL.
As a side effect, this change also limits maximum protocol version to
the newest protocol we know about, TLS 1.3.  This seems to be a good
change, as enabling unknown protocols might have unexpected results.

Additionally, we now explicitly call SSL_CTX_set_min_proto_version()
with 0.  This is expected to help with Debian system-wide default
of MinProtocol set to TLSv1.2, see
http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060411.html.

Note that there is no SSL_CTX_set_min_proto_version macro in BoringSSL,
so we call SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version()
as long as the TLS1_3_VERSION macro is defined.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BoringSSL currently requires SSL_CTX_set_max_proto_version(TLS1_3_VERSION)
to be able to enable TLS 1.3.  This is because by default max protocol
version is set to TLS 1.2, and the SSL_OP_NO_* options are merely used
as a blacklist within the version range specified using the
SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version()
functions.

With this change, we now call SSL_CTX_set_max_proto_version() with an
explicit maximum version set.  This enables TLS 1.3 with BoringSSL.
As a side effect, this change also limits maximum protocol version to
the newest protocol we know about, TLS 1.3.  This seems to be a good
change, as enabling unknown protocols might have unexpected results.

Additionally, we now explicitly call SSL_CTX_set_min_proto_version()
with 0.  This is expected to help with Debian system-wide default
of MinProtocol set to TLSv1.2, see
http://mailman.nginx.org/pipermail/nginx-ru/2017-October/060411.html.

Note that there is no SSL_CTX_set_min_proto_version macro in BoringSSL,
so we call SSL_CTX_set_min_proto_version() and SSL_CTX_set_max_proto_version()
as long as the TLS1_3_VERSION macro is defined.
</pre>
</div>
</content>
</entry>
<entry>
<title>Dav: removed dead store after 8e7a5de61664.</title>
<updated>2018-08-02T10:19:48+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2018-08-02T10:19:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=a6baf5e508cad9d3561ed71a637127deb1e3f40d'/>
<id>a6baf5e508cad9d3561ed71a637127deb1e3f40d</id>
<content type='text'>
Found by Clang Static Analyzer.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Found by Clang Static Analyzer.
</pre>
</div>
</content>
</entry>
</feed>
