<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git, branch release-1.15.3</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>nginx-1.15.3-RELEASE</title>
<updated>2018-08-28T15:36:00+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-28T15:36:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3b8bf4e6a6e7e43e18542b9a6bc96a6e9cc7ccd3'/>
<id>3b8bf4e6a6e7e43e18542b9a6bc96a6e9cc7ccd3</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Updated OpenSSL used for win32 builds.</title>
<updated>2018-08-28T12:05:41+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2018-08-28T12:05:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=719d14de8e5887bcf26d27a940b2703977c52f7e'/>
<id>719d14de8e5887bcf26d27a940b2703977c52f7e</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<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>A link to the error_log directive on nginx.org removed.</title>
<updated>2018-08-10T11:15:05+00:00</updated>
<author>
<name>Maxim Konovalov</name>
<email>maxim@nginx.com</email>
</author>
<published>2018-08-10T11:15:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3c9dcff8bd3d4d6e461113cdaf32771031055ee4'/>
<id>3c9dcff8bd3d4d6e461113cdaf32771031055ee4</id>
<content type='text'>
It makes more harm than good for users and nginx.org
infrastructure.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It makes more harm than good for users and nginx.org
infrastructure.
</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>
</feed>
