<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src, branch release-1.19.5</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>gRPC: RST_STREAM(NO_ERROR) handling after "trailer only" responses.</title>
<updated>2020-11-19T02:41:16+00:00</updated>
<author>
<name>Pavel Pautov</name>
<email>p.pautov@f5.com</email>
</author>
<published>2020-11-19T02:41:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=671cbc18409ec726a540b5cfc0f88bbdc5dba2f1'/>
<id>671cbc18409ec726a540b5cfc0f88bbdc5dba2f1</id>
<content type='text'>
Similarly to the problem fixed in 2096b21fcd10 (ticket #1792),
when a "trailer only" gRPC response (that is, a response with the
END_STREAM flag in the HEADERS frame) was immediately followed by
RST_STREAM(NO_ERROR) in the data preread along with the response
header, RST_STREAM wasn't properly skipped and caused "upstream
rejected request with error 0" errors.
Observed with "unknown service" gRPC errors returned by grpc-go.

Fix is to set ctx-&gt;done if we are going to parse additional data,
so the RST_STREAM(NO_ERROR) is properly skipped.  Additionally, now
ngx_http_grpc_filter() will complain about frames sent for closed
stream if there are any.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similarly to the problem fixed in 2096b21fcd10 (ticket #1792),
when a "trailer only" gRPC response (that is, a response with the
END_STREAM flag in the HEADERS frame) was immediately followed by
RST_STREAM(NO_ERROR) in the data preread along with the response
header, RST_STREAM wasn't properly skipped and caused "upstream
rejected request with error 0" errors.
Observed with "unknown service" gRPC errors returned by grpc-go.

Fix is to set ctx-&gt;done if we are going to parse additional data,
so the RST_STREAM(NO_ERROR) is properly skipped.  Additionally, now
ngx_http_grpc_filter() will complain about frames sent for closed
stream if there are any.
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: "-e" command line option.</title>
<updated>2020-11-19T16:59:00+00:00</updated>
<author>
<name>Igor Ippolitov</name>
<email>iippolitov@nginx.com</email>
</author>
<published>2020-11-19T16:59:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=7e1637a31631955aec753365c7149c64b216d47e'/>
<id>7e1637a31631955aec753365c7149c64b216d47e</id>
<content type='text'>
When installing or running from a non-root user it is sometimes required to
override default, compiled in error log path. There was no way to do this
without rebuilding the binary (ticket #147).

This patch introduced "-e" command line option which allows one to override
compiled in error log path.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When installing or running from a non-root user it is sometimes required to
override default, compiled in error log path. There was no way to do this
without rebuilding the binary (ticket #147).

This patch introduced "-e" command line option which allows one to override
compiled in error log path.
</pre>
</div>
</content>
</entry>
<entry>
<title>Request body: removed error assumption (ticket #2058).</title>
<updated>2020-11-09T19:41:54+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-11-09T19:41:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=a3b5ccd0566e618635303309dd8592aa4cfd7eaf'/>
<id>a3b5ccd0566e618635303309dd8592aa4cfd7eaf</id>
<content type='text'>
Before introduction of request body filter in 42d9beeb22db, the only
possible return code from the ngx_http_request_body_filter() call
without actual buffers was NGX_HTTP_INTERNAL_SERVER_ERROR, and
the code in ngx_http_read_client_request_body() hardcoded the only
possible error to simplify the code of initial call to set rb-&gt;rest.

This is no longer true after introduction of request body filters though,
as a request body filter might need to return other errors, such as 403.
Fix is to preserve the error code actually returned by the call
instead of assuming 500.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Before introduction of request body filter in 42d9beeb22db, the only
possible return code from the ngx_http_request_body_filter() call
without actual buffers was NGX_HTTP_INTERNAL_SERVER_ERROR, and
the code in ngx_http_read_client_request_body() hardcoded the only
possible error to simplify the code of initial call to set rb-&gt;rest.

This is no longer true after introduction of request body filters though,
as a request body filter might need to return other errors, such as 403.
Fix is to preserve the error code actually returned by the call
instead of assuming 500.
</pre>
</div>
</content>
</entry>
<entry>
<title>Request body: improved logging.</title>
<updated>2020-11-09T19:40:53+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-11-09T19:40:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=8ed303c055ee003285231b6d781bfe2dd9c0d3d1'/>
<id>8ed303c055ee003285231b6d781bfe2dd9c0d3d1</id>
<content type='text'>
Added logging before returning NGX_HTTP_INTERNAL_SERVER_ERROR if there
are busy buffers after a request body flush.  This should never happen
with current code, though bugs can be introduced by 3rd party modules.
Make sure debugging will be easy enough.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Added logging before returning NGX_HTTP_INTERNAL_SERVER_ERROR if there
are busy buffers after a request body flush.  This should never happen
with current code, though bugs can be introduced by 3rd party modules.
Make sure debugging will be easy enough.
</pre>
</div>
</content>
</entry>
<entry>
<title>SSL: fixed non-working SSL shutdown on lingering close.</title>
<updated>2020-11-06T20:44:54+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2020-11-06T20:44:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=ad2b9944b012699c225d75e63aeadf61d9ce3367'/>
<id>ad2b9944b012699c225d75e63aeadf61d9ce3367</id>
<content type='text'>
When doing lingering close, the socket was first shut down for writing,
so SSL shutdown initiated after lingering close was not able to send
the close_notify alerts (ticket #2056).

The fix is to call ngx_ssl_shutdown() before shutting down the socket.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When doing lingering close, the socket was first shut down for writing,
so SSL shutdown initiated after lingering close was not able to send
the close_notify alerts (ticket #2056).

The fix is to call ngx_ssl_shutdown() before shutting down the socket.
</pre>
</div>
</content>
</entry>
<entry>
<title>Removed dead code from ngx_http_set_keepalive().</title>
<updated>2020-11-06T20:44:47+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2020-11-06T20:44:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=aad0d1bf1cab58a1b1e1499485e63b7a15ab183c'/>
<id>aad0d1bf1cab58a1b1e1499485e63b7a15ab183c</id>
<content type='text'>
The code removed became dead after 98f03cd8d6cc (0.8.14),
circa when the request reference counting was introduced.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The code removed became dead after 98f03cd8d6cc (0.8.14),
circa when the request reference counting was introduced.
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: added format specifiers to output binary data as hex.</title>
<updated>2020-10-28T07:56:11+00:00</updated>
<author>
<name>Vladimir Homutov</name>
<email>vl@nginx.com</email>
</author>
<published>2020-10-28T07:56:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=3c0427373381097a9e25ccc2cb46bbc1ccac87a2'/>
<id>3c0427373381097a9e25ccc2cb46bbc1ccac87a2</id>
<content type='text'>
Now "s", "V", and "v" format specifiers may be prefixed with "x" (lowercase)
or "X" (uppercase) to output corresponding data in hexadecimal format.

In collaboration with Maxim Dounin.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Now "s", "V", and "v" format specifiers may be prefixed with "x" (lowercase)
or "X" (uppercase) to output corresponding data in hexadecimal format.

In collaboration with Maxim Dounin.
</pre>
</div>
</content>
</entry>
<entry>
<title>Version bump.</title>
<updated>2020-11-05T19:37:27+00:00</updated>
<author>
<name>Vladimir Homutov</name>
<email>vl@nginx.com</email>
</author>
<published>2020-11-05T19:37:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=c566d799938312197e4fc351ab0b977b72d89e8f'/>
<id>c566d799938312197e4fc351ab0b977b72d89e8f</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>SSL: ssl_reject_handshake directive (ticket #195).</title>
<updated>2020-10-22T15:02:28+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-10-22T15:02:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=9cdb278454367448366354f2786b36c1fef1f92e'/>
<id>9cdb278454367448366354f2786b36c1fef1f92e</id>
<content type='text'>
In some cases it might be needed to reject SSL handshake based on SNI
server name provided, for example, to make sure an invalid certificate
is not returned to clients trying to contact a name-based virtual server
without SSL configured.  Previously, a "ssl_ciphers aNULL;" was used for
this.  This workaround, however, is not compatible with TLSv1.3, in
particular, when using BoringSSL, where it is not possible to configure
TLSv1.3 ciphers at all.

With this change, the ssl_reject_handshake directive is introduced,
which instructs nginx to reject SSL handshakes with an "unrecognized_name"
alert in a particular server block.

For example, to reject handshake with names other than example.com,
one can use the following configuration:

    server {
        listen 443 ssl;
        ssl_reject_handshake on;
    }

    server {
        listen 443 ssl;
        server_name example.com;
        ssl_certificate example.com.crt;
        ssl_certificate_key example.com.key;
    }

The following configuration can be used to reject all SSL handshakes
without SNI server name provided:

    server {
        listen 443 ssl;
        ssl_reject_handshake on;
    }

    server {
        listen 443 ssl;
        server_name ~^;
        ssl_certificate example.crt;
        ssl_certificate_key example.key;
    }

Additionally, the ssl_reject_handshake directive makes configuring
certificates for the default server block optional.  If no certificates
are configured in the default server for a given listening socket,
certificates must be defined in all non-default server blocks with
the listening socket in question.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In some cases it might be needed to reject SSL handshake based on SNI
server name provided, for example, to make sure an invalid certificate
is not returned to clients trying to contact a name-based virtual server
without SSL configured.  Previously, a "ssl_ciphers aNULL;" was used for
this.  This workaround, however, is not compatible with TLSv1.3, in
particular, when using BoringSSL, where it is not possible to configure
TLSv1.3 ciphers at all.

With this change, the ssl_reject_handshake directive is introduced,
which instructs nginx to reject SSL handshakes with an "unrecognized_name"
alert in a particular server block.

For example, to reject handshake with names other than example.com,
one can use the following configuration:

    server {
        listen 443 ssl;
        ssl_reject_handshake on;
    }

    server {
        listen 443 ssl;
        server_name example.com;
        ssl_certificate example.com.crt;
        ssl_certificate_key example.com.key;
    }

The following configuration can be used to reject all SSL handshakes
without SNI server name provided:

    server {
        listen 443 ssl;
        ssl_reject_handshake on;
    }

    server {
        listen 443 ssl;
        server_name ~^;
        ssl_certificate example.crt;
        ssl_certificate_key example.key;
    }

Additionally, the ssl_reject_handshake directive makes configuring
certificates for the default server block optional.  If no certificates
are configured in the default server for a given listening socket,
certificates must be defined in all non-default server blocks with
the listening socket in question.
</pre>
</div>
</content>
</entry>
<entry>
<title>Stream: proxy_ssl_conf_command directive.</title>
<updated>2020-10-22T15:00:27+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2020-10-22T15:00:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f9a37243c9a86fcc318ee77fa49c2b1bfe35b6b5'/>
<id>f9a37243c9a86fcc318ee77fa49c2b1bfe35b6b5</id>
<content type='text'>
Similarly to ssl_conf_command, proxy_ssl_conf_command can be used to
set arbitrary OpenSSL configuration parameters as long as nginx is
compiled with OpenSSL 1.0.2 or later, when connecting to upstream
servers with SSL.  Full list of available configuration commands
can be found in the SSL_CONF_cmd manual page
(https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similarly to ssl_conf_command, proxy_ssl_conf_command can be used to
set arbitrary OpenSSL configuration parameters as long as nginx is
compiled with OpenSSL 1.0.2 or later, when connecting to upstream
servers with SSL.  Full list of available configuration commands
can be found in the SSL_CONF_cmd manual page
(https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html).
</pre>
</div>
</content>
</entry>
</feed>
