From osa at FreeBSD.org.ru  Mon Feb  2 14:59:18 2026
From: osa at FreeBSD.org.ru (=?iso-8859-1?q?Sergey_A=2E_Osokin?=)
Date: Mon, 02 Feb 2026 17:59:18 +0300
Subject: [PATCH] Fix the $r request object methods order
Message-ID: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>

# HG changeset patch
# User Sergey A. Osokin <osa at FreeBSD.org.ru>
# Date 1770044238 -10800
#      Mon Feb 02 17:57:18 2026 +0300
# Node ID 6589496596a1a7c180c66972e43ceca26504e66e
# Parent  c6cbc552bd6a56e79276518253637c71628cbe16
Fix the $r request object methods order

diff -r c6cbc552bd6a -r 6589496596a1 xml/en/docs/http/ngx_http_perl_module.xml
--- a/xml/en/docs/http/ngx_http_perl_module.xml	Tue Dec 16 16:20:31 2025 +0300
+++ b/xml/en/docs/http/ngx_http_perl_module.xml	Mon Feb 02 17:57:18 2026 +0300
@@ -219,16 +219,31 @@
 <para>
 <list type="tag">
 
+<tag-name><literal>$r->allow_ranges</literal></tag-name>
+<tag-desc>
+enables the use of byte ranges when sending responses.
+</tag-desc>
+
 <tag-name><literal>$r->args</literal></tag-name>
 <tag-desc>
 returns request arguments.
 </tag-desc>
 
+<tag-name><literal>$r->discard_request_body</literal></tag-name>
+<tag-desc>
+instructs nginx to discard the request body.
+</tag-desc>
+
 <tag-name><literal>$r->filename</literal></tag-name>
 <tag-desc>
 returns a filename corresponding to the request URI.
 </tag-desc>
 
+<tag-name><literal>$r->flush</literal></tag-name>
+<tag-desc>
+immediately sends data to the client.
+</tag-desc>
+
 <tag-name>
     <literal>$r->has_request_body(<value>handler</value>)</literal>
 </tag-name>
@@ -275,16 +290,6 @@
 </example>
 </tag-desc>
 
-<tag-name><literal>$r->allow_ranges</literal></tag-name>
-<tag-desc>
-enables the use of byte ranges when sending responses.
-</tag-desc>
-
-<tag-name><literal>$r->discard_request_body</literal></tag-name>
-<tag-desc>
-instructs nginx to discard the request body.
-</tag-desc>
-
 <tag-name><literal>$r->header_in(<value>field</value>)</literal></tag-name>
 <tag-desc>
 returns the value of the specified client request header field.
@@ -331,6 +336,11 @@
 passes data to a client.
 </tag-desc>
 
+<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-desc>
+returns the client IP address.
+</tag-desc>
+
 <tag-name><literal>$r->request_body</literal></tag-name>
 <tag-desc>
 returns the client request body if it has not been
@@ -356,14 +366,15 @@
 returns the client request HTTP method.
 </tag-desc>
 
-<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-name>
+    <literal>$r->send_http_header([<value>type</value>])</literal>
+</tag-name>
 <tag-desc>
-returns the client IP address.
-</tag-desc>
-
-<tag-name><literal>$r->flush</literal></tag-name>
-<tag-desc>
-immediately sends data to the client.
+sends the response header to the client.
+The optional <value>type</value> parameter sets the value of
+the <header>Content-Type</header> response header field.
+If the value is an empty string, the <header>Content-Type</header>
+header field will not be sent.
 </tag-desc>
 
 <tag-name>
@@ -380,22 +391,6 @@
 </tag-desc>
 
 <tag-name>
-    <literal>$r->send_http_header([<value>type</value>])</literal>
-</tag-name>
-<tag-desc>
-sends the response header to the client.
-The optional <value>type</value> parameter sets the value of
-the <header>Content-Type</header> response header field.
-If the value is an empty string, the <header>Content-Type</header>
-header field will not be sent.
-</tag-desc>
-
-<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
-<tag-desc>
-sets a response code.
-</tag-desc>
-
-<tag-name>
     <literal>$r->sleep(<value>milliseconds</value>,
     <value>handler</value>)</literal>
 </tag-name>
@@ -438,6 +433,11 @@
 </example>
 </tag-desc>
 
+<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
+<tag-desc>
+sets a response code.
+</tag-desc>
+
 <tag-name><literal>$r->unescape(<value>text</value>)</literal></tag-name>
 <tag-desc>
 decodes a text encoded in the ?%XX? form.

From osa at FreeBSD.org.ru  Mon Feb  2 17:56:03 2026
From: osa at FreeBSD.org.ru (=?iso-8859-1?q?Sergey_A=2E_Osokin?=)
Date: Mon, 02 Feb 2026 20:56:03 +0300
Subject: [PATCH] Remove needless dot symbol
Message-ID: <6305a5da802e70da9d6c.1770054963@mp2.macomnet.net>

# HG changeset patch
# User Sergey A. Osokin <osa at FreeBSD.org.ru>
# Date 1770054926 -10800
#      Mon Feb 02 20:55:26 2026 +0300
# Node ID 6305a5da802e70da9d6cb296972254ee1bfde350
# Parent  c6cbc552bd6a56e79276518253637c71628cbe16
Remove needless dot symbol

diff -r c6cbc552bd6a -r 6305a5da802e xml/en/docs/switches.xml
--- a/xml/en/docs/switches.xml	Tue Dec 16 16:20:31 2025 +0300
+++ b/xml/en/docs/switches.xml	Mon Feb 02 20:55:26 2026 +0300
@@ -67,7 +67,7 @@
 <listitem>
 <literal>reload</literal>&mdash;reload configuration,
 start the new worker process with a new configuration,
-gracefully shut down old worker processes.
+gracefully shut down old worker processes
 </listitem>
 <listitem>
 <literal>reopen</literal>&mdash;reopen log files

From mdounin at mdounin.ru  Mon Feb  2 17:59:58 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Mon, 2 Feb 2026 20:59:58 +0300
Subject: [PATCH] Fix the $r request object methods order
In-Reply-To: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
References: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
Message-ID: <aYDmHhAil4Cjt7M5@mdounin.ru>

Hello!

On Mon, Feb 02, 2026 at 05:59:18PM +0300, Sergey A. Osokin wrote:

> # HG changeset patch
> # User Sergey A. Osokin <osa at FreeBSD.org.ru>
> # Date 1770044238 -10800
> #      Mon Feb 02 17:57:18 2026 +0300
> # Node ID 6589496596a1a7c180c66972e43ceca26504e66e
> # Parent  c6cbc552bd6a56e79276518253637c71628cbe16
> Fix the $r request object methods order

Should be:

Fixed the $r request object methods order.

Note "Fixed" and the trailing dot.

Also, it might be good idea to explicitly mention the perl module, 
so the change would be more obvious when looking through the 
repository history.  Something like:

Fixed order of perl request object methods.

YMMV.

> 
> diff -r c6cbc552bd6a -r 6589496596a1 xml/en/docs/http/ngx_http_perl_module.xml
> --- a/xml/en/docs/http/ngx_http_perl_module.xml	Tue Dec 16 16:20:31 2025 +0300
> +++ b/xml/en/docs/http/ngx_http_perl_module.xml	Mon Feb 02 17:57:18 2026 +0300
> @@ -219,16 +219,31 @@

For changes which aren't language-specific (like fixing spelling) 
the document revision should be bumped, as seen in the "rev" 
attribute of the module tag.  This ensures that translations (or, 
rather, translation, since we have only one now) are marked as 
outdated, and can be updated.

Also, it is usually a good idea to update Russian translation 
at the same time if possible.

>  <para>
>  <list type="tag">
>  
> +<tag-name><literal>$r->allow_ranges</literal></tag-name>
> +<tag-desc>
> +enables the use of byte ranges when sending responses.
> +</tag-desc>
> +

[...]

Otherwise looks good.

-- 
Maxim Dounin
http://mdounin.ru/

From osa at FreeBSD.org.ru  Mon Feb  2 18:19:55 2026
From: osa at FreeBSD.org.ru (=?iso-8859-1?q?Sergey_A=2E_Osokin?=)
Date: Mon, 02 Feb 2026 21:19:55 +0300
Subject: [PATCH] Fixed order of perl request object methods
In-Reply-To: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
References: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
Message-ID: <84b61c18c557c80e0ac1.1770056395@mp2.macomnet.net>

# HG changeset patch
# User Sergey A. Osokin <osa at FreeBSD.org.ru>
# Date 1770056261 -10800
#      Mon Feb 02 21:17:41 2026 +0300
# Node ID 84b61c18c557c80e0ac16aee7a44b3b217f52fa5
# Parent  c6cbc552bd6a56e79276518253637c71628cbe16
Fixed order of perl request object methods.

diff -r c6cbc552bd6a -r 84b61c18c557 xml/en/docs/http/ngx_http_perl_module.xml
--- a/xml/en/docs/http/ngx_http_perl_module.xml	Tue Dec 16 16:20:31 2025 +0300
+++ b/xml/en/docs/http/ngx_http_perl_module.xml	Mon Feb 02 21:17:41 2026 +0300
@@ -219,16 +219,31 @@
 <para>
 <list type="tag">
 
+<tag-name><literal>$r->allow_ranges</literal></tag-name>
+<tag-desc>
+enables the use of byte ranges when sending responses.
+</tag-desc>
+
 <tag-name><literal>$r->args</literal></tag-name>
 <tag-desc>
 returns request arguments.
 </tag-desc>
 
+<tag-name><literal>$r->discard_request_body</literal></tag-name>
+<tag-desc>
+instructs nginx to discard the request body.
+</tag-desc>
+
 <tag-name><literal>$r->filename</literal></tag-name>
 <tag-desc>
 returns a filename corresponding to the request URI.
 </tag-desc>
 
+<tag-name><literal>$r->flush</literal></tag-name>
+<tag-desc>
+immediately sends data to the client.
+</tag-desc>
+
 <tag-name>
     <literal>$r->has_request_body(<value>handler</value>)</literal>
 </tag-name>
@@ -275,16 +290,6 @@
 </example>
 </tag-desc>
 
-<tag-name><literal>$r->allow_ranges</literal></tag-name>
-<tag-desc>
-enables the use of byte ranges when sending responses.
-</tag-desc>
-
-<tag-name><literal>$r->discard_request_body</literal></tag-name>
-<tag-desc>
-instructs nginx to discard the request body.
-</tag-desc>
-
 <tag-name><literal>$r->header_in(<value>field</value>)</literal></tag-name>
 <tag-desc>
 returns the value of the specified client request header field.
@@ -331,6 +336,11 @@
 passes data to a client.
 </tag-desc>
 
+<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-desc>
+returns the client IP address.
+</tag-desc>
+
 <tag-name><literal>$r->request_body</literal></tag-name>
 <tag-desc>
 returns the client request body if it has not been
@@ -356,14 +366,15 @@
 returns the client request HTTP method.
 </tag-desc>
 
-<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-name>
+    <literal>$r->send_http_header([<value>type</value>])</literal>
+</tag-name>
 <tag-desc>
-returns the client IP address.
-</tag-desc>
-
-<tag-name><literal>$r->flush</literal></tag-name>
-<tag-desc>
-immediately sends data to the client.
+sends the response header to the client.
+The optional <value>type</value> parameter sets the value of
+the <header>Content-Type</header> response header field.
+If the value is an empty string, the <header>Content-Type</header>
+header field will not be sent.
 </tag-desc>
 
 <tag-name>
@@ -380,22 +391,6 @@
 </tag-desc>
 
 <tag-name>
-    <literal>$r->send_http_header([<value>type</value>])</literal>
-</tag-name>
-<tag-desc>
-sends the response header to the client.
-The optional <value>type</value> parameter sets the value of
-the <header>Content-Type</header> response header field.
-If the value is an empty string, the <header>Content-Type</header>
-header field will not be sent.
-</tag-desc>
-
-<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
-<tag-desc>
-sets a response code.
-</tag-desc>
-
-<tag-name>
     <literal>$r->sleep(<value>milliseconds</value>,
     <value>handler</value>)</literal>
 </tag-name>
@@ -438,6 +433,11 @@
 </example>
 </tag-desc>
 
+<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
+<tag-desc>
+sets a response code.
+</tag-desc>
+
 <tag-name><literal>$r->unescape(<value>text</value>)</literal></tag-name>
 <tag-desc>
 decodes a text encoded in the ?%XX? form.

From osa at FreeBSD.org.ru  Mon Feb  2 18:26:27 2026
From: osa at FreeBSD.org.ru (=?iso-8859-1?q?Sergey_A=2E_Osokin?=)
Date: Mon, 02 Feb 2026 21:26:27 +0300
Subject: [PATCH] Removed a needless dot symbol
In-Reply-To: <6305a5da802e70da9d6c.1770054963@mp2.macomnet.net>
References: <6305a5da802e70da9d6c.1770054963@mp2.macomnet.net>
Message-ID: <64e0cb07799425665623.1770056787@mp2.macomnet.net>

# HG changeset patch
# User Sergey A. Osokin <osa at FreeBSD.org.ru>
# Date 1770056711 -10800
#      Mon Feb 02 21:25:11 2026 +0300
# Node ID 64e0cb077994256656236f008924337e1c12dd4e
# Parent  c6cbc552bd6a56e79276518253637c71628cbe16
Removed a needless dot symbol.

diff -r c6cbc552bd6a -r 64e0cb077994 xml/en/docs/switches.xml
--- a/xml/en/docs/switches.xml	Tue Dec 16 16:20:31 2025 +0300
+++ b/xml/en/docs/switches.xml	Mon Feb 02 21:25:11 2026 +0300
@@ -67,7 +67,7 @@
 <listitem>
 <literal>reload</literal>&mdash;reload configuration,
 start the new worker process with a new configuration,
-gracefully shut down old worker processes.
+gracefully shut down old worker processes
 </listitem>
 <listitem>
 <literal>reopen</literal>&mdash;reopen log files

From osa at FreeBSD.org.ru  Mon Feb  2 19:42:22 2026
From: osa at FreeBSD.org.ru (=?iso-8859-1?q?Sergey_A=2E_Osokin?=)
Date: Mon, 02 Feb 2026 22:42:22 +0300
Subject: [PATCH] Fixed order of perl request object methods
In-Reply-To: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
References: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
Message-ID: <d83d66357a77d374475c.1770061342@mp2.macomnet.net>

# HG changeset patch
# User Sergey A. Osokin <osa at FreeBSD.org.ru>
# Date 1770061280 -10800
#      Mon Feb 02 22:41:20 2026 +0300
# Node ID d83d66357a77d374475c9db75b5487b68a380178
# Parent  c6cbc552bd6a56e79276518253637c71628cbe16
Fixed order of perl request object methods.

diff -r c6cbc552bd6a -r d83d66357a77 xml/en/docs/http/ngx_http_perl_module.xml
--- a/xml/en/docs/http/ngx_http_perl_module.xml	Tue Dec 16 16:20:31 2025 +0300
+++ b/xml/en/docs/http/ngx_http_perl_module.xml	Mon Feb 02 22:41:20 2026 +0300
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_perl_module"
         link="/en/docs/http/ngx_http_perl_module.html"
         lang="en"
-        rev="8">
+        rev="9">
 
 <section id="summary">
 
@@ -219,16 +219,31 @@
 <para>
 <list type="tag">
 
+<tag-name><literal>$r->allow_ranges</literal></tag-name>
+<tag-desc>
+enables the use of byte ranges when sending responses.
+</tag-desc>
+
 <tag-name><literal>$r->args</literal></tag-name>
 <tag-desc>
 returns request arguments.
 </tag-desc>
 
+<tag-name><literal>$r->discard_request_body</literal></tag-name>
+<tag-desc>
+instructs nginx to discard the request body.
+</tag-desc>
+
 <tag-name><literal>$r->filename</literal></tag-name>
 <tag-desc>
 returns a filename corresponding to the request URI.
 </tag-desc>
 
+<tag-name><literal>$r->flush</literal></tag-name>
+<tag-desc>
+immediately sends data to the client.
+</tag-desc>
+
 <tag-name>
     <literal>$r->has_request_body(<value>handler</value>)</literal>
 </tag-name>
@@ -275,16 +290,6 @@
 </example>
 </tag-desc>
 
-<tag-name><literal>$r->allow_ranges</literal></tag-name>
-<tag-desc>
-enables the use of byte ranges when sending responses.
-</tag-desc>
-
-<tag-name><literal>$r->discard_request_body</literal></tag-name>
-<tag-desc>
-instructs nginx to discard the request body.
-</tag-desc>
-
 <tag-name><literal>$r->header_in(<value>field</value>)</literal></tag-name>
 <tag-desc>
 returns the value of the specified client request header field.
@@ -331,6 +336,11 @@
 passes data to a client.
 </tag-desc>
 
+<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-desc>
+returns the client IP address.
+</tag-desc>
+
 <tag-name><literal>$r->request_body</literal></tag-name>
 <tag-desc>
 returns the client request body if it has not been
@@ -356,14 +366,15 @@
 returns the client request HTTP method.
 </tag-desc>
 
-<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-name>
+    <literal>$r->send_http_header([<value>type</value>])</literal>
+</tag-name>
 <tag-desc>
-returns the client IP address.
-</tag-desc>
-
-<tag-name><literal>$r->flush</literal></tag-name>
-<tag-desc>
-immediately sends data to the client.
+sends the response header to the client.
+The optional <value>type</value> parameter sets the value of
+the <header>Content-Type</header> response header field.
+If the value is an empty string, the <header>Content-Type</header>
+header field will not be sent.
 </tag-desc>
 
 <tag-name>
@@ -380,22 +391,6 @@
 </tag-desc>
 
 <tag-name>
-    <literal>$r->send_http_header([<value>type</value>])</literal>
-</tag-name>
-<tag-desc>
-sends the response header to the client.
-The optional <value>type</value> parameter sets the value of
-the <header>Content-Type</header> response header field.
-If the value is an empty string, the <header>Content-Type</header>
-header field will not be sent.
-</tag-desc>
-
-<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
-<tag-desc>
-sets a response code.
-</tag-desc>
-
-<tag-name>
     <literal>$r->sleep(<value>milliseconds</value>,
     <value>handler</value>)</literal>
 </tag-name>
@@ -438,6 +433,11 @@
 </example>
 </tag-desc>
 
+<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
+<tag-desc>
+sets a response code.
+</tag-desc>
+
 <tag-name><literal>$r->unescape(<value>text</value>)</literal></tag-name>
 <tag-desc>
 decodes a text encoded in the ?%XX? form.
diff -r c6cbc552bd6a -r d83d66357a77 xml/ru/docs/http/ngx_http_perl_module.xml
--- a/xml/ru/docs/http/ngx_http_perl_module.xml	Tue Dec 16 16:20:31 2025 +0300
+++ b/xml/ru/docs/http/ngx_http_perl_module.xml	Mon Feb 02 22:41:20 2026 +0300
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_perl_module"
         link="/ru/docs/http/ngx_http_perl_module.html"
         lang="ru"
-        rev="8">
+        rev="9">
 
 <section id="summary">
 
@@ -220,16 +220,31 @@
 <para>
 <list type="tag">
 
+<tag-name><literal>$r->allow_ranges</literal></tag-name>
+<tag-desc>
+????????? ???????????? ????????? ???? (byte ranges) ??? ???????? ??????.
+</tag-desc>
+
 <tag-name><literal>$r->args</literal></tag-name>
 <tag-desc>
 ?????????? ????????? ???????.
 </tag-desc>
 
+<tag-name><literal>$r->discard_request_body</literal></tag-name>
+<tag-desc>
+????????? nginx ???????????? ???? ???????.
+</tag-desc>
+
 <tag-name><literal>$r->filename</literal></tag-name>
 <tag-desc>
 ?????????? ??? ?????, ??????????????? URI ???????.
 </tag-desc>
 
+<tag-name><literal>$r->flush</literal></tag-name>
+<tag-desc>
+?????????? ???????? ?????? ???????.
+</tag-desc>
+
 <tag-name>
     <literal>$r->has_request_body(<value>??????????</value>)</literal>
 </tag-name>
@@ -276,16 +291,6 @@
 </example>
 </tag-desc>
 
-<tag-name><literal>$r->allow_ranges</literal></tag-name>
-<tag-desc>
-????????? ???????????? ????????? ???? (byte ranges) ??? ???????? ??????.
-</tag-desc>
-
-<tag-name><literal>$r->discard_request_body</literal></tag-name>
-<tag-desc>
-????????? nginx ???????????? ???? ???????.
-</tag-desc>
-
 <tag-name><literal>$r->header_in(<value>????</value>)</literal></tag-name>
 <tag-desc>
 ?????????? ???????? ????????? ???? ? ????????? ??????? ???????.
@@ -331,6 +336,11 @@
 ????? ???????? ??????? ??????.
 </tag-desc>
 
+<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-desc>
+?????????? IP-????? ???????.
+</tag-desc>
+
 <tag-name><literal>$r->request_body</literal></tag-name>
 <tag-desc>
 ?????????? ???? ??????? ??????? ??? ???????,
@@ -356,14 +366,15 @@
 ?????????? HTTP-????? ??????? ???????.
 </tag-desc>
 
-<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-name>
+    <literal>$r->send_http_header([<value>???</value>])</literal>
+</tag-name>
 <tag-desc>
-?????????? IP-????? ???????.
-</tag-desc>
-
-<tag-name><literal>$r->flush</literal></tag-name>
-<tag-desc>
-?????????? ???????? ?????? ???????.
+???????? ??????? ????????? ??????.
+?????????????? ???????? <value>???</value> ????????????? ???????? ????
+<header>Content-Type</header> ? ????????? ??????.
+?????? ?????? ? ???????? ???? ????????? ???????? ????
+<header>Content-Type</header>.
 </tag-desc>
 
 <tag-name>
@@ -380,22 +391,6 @@
 </tag-desc>
 
 <tag-name>
-    <literal>$r->send_http_header([<value>???</value>])</literal>
-</tag-name>
-<tag-desc>
-???????? ??????? ????????? ??????.
-?????????????? ???????? <value>???</value> ????????????? ???????? ????
-<header>Content-Type</header> ? ????????? ??????.
-?????? ?????? ? ???????? ???? ????????? ???????? ????
-<header>Content-Type</header>.
-</tag-desc>
-
-<tag-name><literal>$r->status(<value>???</value>)</literal></tag-name>
-<tag-desc>
-????????????? ??? ??????.
-</tag-desc>
-
-<tag-name>
     <literal>$r->sleep(<value>????????????</value>,
     <value>??????????</value>)</literal>
 </tag-name>
@@ -438,6 +433,11 @@
 </example>
 </tag-desc>
 
+<tag-name><literal>$r->status(<value>???</value>)</literal></tag-name>
+<tag-desc>
+????????????? ??? ??????.
+</tag-desc>
+
 <tag-name><literal>$r->unescape(<value>?????</value>)</literal></tag-name>
 <tag-desc>
 ?????????? ?????, ???????? ? ???? ?%XX?.

From mdounin at mdounin.ru  Tue Feb  3 13:22:49 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Feb 2026 16:22:49 +0300
Subject: [nginx-site] Fixed order of perl request object methods.
Message-ID: <hg.d83d66357a77.1770124969.-5824411201450104584@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/d83d66357a77
branches:  
changeset: 3126:d83d66357a77
user:      Sergey A. Osokin <osa at FreeBSD.org.ru>
date:      Mon Feb 02 22:41:20 2026 +0300
description:
Fixed order of perl request object methods.

diffstat:

 xml/en/docs/http/ngx_http_perl_module.xml |  68 +++++++++++++++---------------
 xml/ru/docs/http/ngx_http_perl_module.xml |  68 +++++++++++++++---------------
 2 files changed, 68 insertions(+), 68 deletions(-)

diffs (262 lines):

diff --git a/xml/en/docs/http/ngx_http_perl_module.xml b/xml/en/docs/http/ngx_http_perl_module.xml
--- a/xml/en/docs/http/ngx_http_perl_module.xml
+++ b/xml/en/docs/http/ngx_http_perl_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_perl_module"
         link="/en/docs/http/ngx_http_perl_module.html"
         lang="en"
-        rev="8">
+        rev="9">
 
 <section id="summary">
 
@@ -219,16 +219,31 @@ An SSI command calling Perl has the foll
 <para>
 <list type="tag">
 
+<tag-name><literal>$r->allow_ranges</literal></tag-name>
+<tag-desc>
+enables the use of byte ranges when sending responses.
+</tag-desc>
+
 <tag-name><literal>$r->args</literal></tag-name>
 <tag-desc>
 returns request arguments.
 </tag-desc>
 
+<tag-name><literal>$r->discard_request_body</literal></tag-name>
+<tag-desc>
+instructs nginx to discard the request body.
+</tag-desc>
+
 <tag-name><literal>$r->filename</literal></tag-name>
 <tag-desc>
 returns a filename corresponding to the request URI.
 </tag-desc>
 
+<tag-name><literal>$r->flush</literal></tag-name>
+<tag-desc>
+immediately sends data to the client.
+</tag-desc>
+
 <tag-name>
     <literal>$r->has_request_body(<value>handler</value>)</literal>
 </tag-name>
@@ -275,16 +290,6 @@ 1;
 </example>
 </tag-desc>
 
-<tag-name><literal>$r->allow_ranges</literal></tag-name>
-<tag-desc>
-enables the use of byte ranges when sending responses.
-</tag-desc>
-
-<tag-name><literal>$r->discard_request_body</literal></tag-name>
-<tag-desc>
-instructs nginx to discard the request body.
-</tag-desc>
-
 <tag-name><literal>$r->header_in(<value>field</value>)</literal></tag-name>
 <tag-desc>
 returns the value of the specified client request header field.
@@ -331,6 +336,11 @@ will be appended to the message.
 passes data to a client.
 </tag-desc>
 
+<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-desc>
+returns the client IP address.
+</tag-desc>
+
 <tag-name><literal>$r->request_body</literal></tag-name>
 <tag-desc>
 returns the client request body if it has not been
@@ -356,14 +366,15 @@ should be enabled.
 returns the client request HTTP method.
 </tag-desc>
 
-<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-name>
+    <literal>$r->send_http_header([<value>type</value>])</literal>
+</tag-name>
 <tag-desc>
-returns the client IP address.
-</tag-desc>
-
-<tag-name><literal>$r->flush</literal></tag-name>
-<tag-desc>
-immediately sends data to the client.
+sends the response header to the client.
+The optional <value>type</value> parameter sets the value of
+the <header>Content-Type</header> response header field.
+If the value is an empty string, the <header>Content-Type</header>
+header field will not be sent.
 </tag-desc>
 
 <tag-name>
@@ -380,22 +391,6 @@ has completed.
 </tag-desc>
 
 <tag-name>
-    <literal>$r->send_http_header([<value>type</value>])</literal>
-</tag-name>
-<tag-desc>
-sends the response header to the client.
-The optional <value>type</value> parameter sets the value of
-the <header>Content-Type</header> response header field.
-If the value is an empty string, the <header>Content-Type</header>
-header field will not be sent.
-</tag-desc>
-
-<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
-<tag-desc>
-sets a response code.
-</tag-desc>
-
-<tag-name>
     <literal>$r->sleep(<value>milliseconds</value>,
     <value>handler</value>)</literal>
 </tag-name>
@@ -438,6 +433,11 @@ 1;
 </example>
 </tag-desc>
 
+<tag-name><literal>$r->status(<value>code</value>)</literal></tag-name>
+<tag-desc>
+sets a response code.
+</tag-desc>
+
 <tag-name><literal>$r->unescape(<value>text</value>)</literal></tag-name>
 <tag-desc>
 decodes a text encoded in the ?%XX? form.
diff --git a/xml/ru/docs/http/ngx_http_perl_module.xml b/xml/ru/docs/http/ngx_http_perl_module.xml
--- a/xml/ru/docs/http/ngx_http_perl_module.xml
+++ b/xml/ru/docs/http/ngx_http_perl_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_perl_module"
         link="/ru/docs/http/ngx_http_perl_module.html"
         lang="ru"
-        rev="8">
+        rev="9">
 
 <section id="summary">
 
@@ -220,16 +220,31 @@ 1;
 <para>
 <list type="tag">
 
+<tag-name><literal>$r->allow_ranges</literal></tag-name>
+<tag-desc>
+????????? ???????????? ????????? ???? (byte ranges) ??? ???????? ??????.
+</tag-desc>
+
 <tag-name><literal>$r->args</literal></tag-name>
 <tag-desc>
 ?????????? ????????? ???????.
 </tag-desc>
 
+<tag-name><literal>$r->discard_request_body</literal></tag-name>
+<tag-desc>
+????????? nginx ???????????? ???? ???????.
+</tag-desc>
+
 <tag-name><literal>$r->filename</literal></tag-name>
 <tag-desc>
 ?????????? ??? ?????, ??????????????? URI ???????.
 </tag-desc>
 
+<tag-name><literal>$r->flush</literal></tag-name>
+<tag-desc>
+?????????? ???????? ?????? ???????.
+</tag-desc>
+
 <tag-name>
     <literal>$r->has_request_body(<value>??????????</value>)</literal>
 </tag-name>
@@ -276,16 +291,6 @@ 1;
 </example>
 </tag-desc>
 
-<tag-name><literal>$r->allow_ranges</literal></tag-name>
-<tag-desc>
-????????? ???????????? ????????? ???? (byte ranges) ??? ???????? ??????.
-</tag-desc>
-
-<tag-name><literal>$r->discard_request_body</literal></tag-name>
-<tag-desc>
-????????? nginx ???????????? ???? ???????.
-</tag-desc>
-
 <tag-name><literal>$r->header_in(<value>????</value>)</literal></tag-name>
 <tag-desc>
 ?????????? ???????? ????????? ???? ? ????????? ??????? ???????.
@@ -331,6 +336,11 @@ 1;
 ????? ???????? ??????? ??????.
 </tag-desc>
 
+<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-desc>
+?????????? IP-????? ???????.
+</tag-desc>
+
 <tag-name><literal>$r->request_body</literal></tag-name>
 <tag-desc>
 ?????????? ???? ??????? ??????? ??? ???????,
@@ -356,14 +366,15 @@ 1;
 ?????????? HTTP-????? ??????? ???????.
 </tag-desc>
 
-<tag-name><literal>$r->remote_addr</literal></tag-name>
+<tag-name>
+    <literal>$r->send_http_header([<value>???</value>])</literal>
+</tag-name>
 <tag-desc>
-?????????? IP-????? ???????.
-</tag-desc>
-
-<tag-name><literal>$r->flush</literal></tag-name>
-<tag-desc>
-?????????? ???????? ?????? ???????.
+???????? ??????? ????????? ??????.
+?????????????? ???????? <value>???</value> ????????????? ???????? ????
+<header>Content-Type</header> ? ????????? ??????.
+?????? ?????? ? ???????? ???? ????????? ???????? ????
+<header>Content-Type</header>.
 </tag-desc>
 
 <tag-name>
@@ -380,22 +391,6 @@ 1;
 </tag-desc>
 
 <tag-name>
-    <literal>$r->send_http_header([<value>???</value>])</literal>
-</tag-name>
-<tag-desc>
-???????? ??????? ????????? ??????.
-?????????????? ???????? <value>???</value> ????????????? ???????? ????
-<header>Content-Type</header> ? ????????? ??????.
-?????? ?????? ? ???????? ???? ????????? ???????? ????
-<header>Content-Type</header>.
-</tag-desc>
-
-<tag-name><literal>$r->status(<value>???</value>)</literal></tag-name>
-<tag-desc>
-????????????? ??? ??????.
-</tag-desc>
-
-<tag-name>
     <literal>$r->sleep(<value>????????????</value>,
     <value>??????????</value>)</literal>
 </tag-name>
@@ -438,6 +433,11 @@ 1;
 </example>
 </tag-desc>
 
+<tag-name><literal>$r->status(<value>???</value>)</literal></tag-name>
+<tag-desc>
+????????????? ??? ??????.
+</tag-desc>
+
 <tag-name><literal>$r->unescape(<value>?????</value>)</literal></tag-name>
 <tag-desc>
 ?????????? ?????, ???????? ? ???? ?%XX?.

From mdounin at mdounin.ru  Tue Feb  3 13:22:49 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Feb 2026 16:22:49 +0300
Subject: [nginx-site] Removed a needless dot symbol.
Message-ID: <hg.112cfe479bd4.1770124969.-5824411201450104584@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/112cfe479bd4
branches:  
changeset: 3127:112cfe479bd4
user:      Sergey A. Osokin <osa at FreeBSD.org.ru>
date:      Mon Feb 02 21:25:11 2026 +0300
description:
Removed a needless dot symbol.

diffstat:

 xml/en/docs/switches.xml |  4 ++--
 xml/ru/docs/switches.xml |  4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diffs (42 lines):

diff --git a/xml/en/docs/switches.xml b/xml/en/docs/switches.xml
--- a/xml/en/docs/switches.xml
+++ b/xml/en/docs/switches.xml
@@ -8,7 +8,7 @@
 <article name="Command-line parameters"
          link="/en/docs/switches.html"
          lang="en"
-         rev="4">
+         rev="5">
 
 <section>
 
@@ -67,7 +67,7 @@ The argument <i>signal</i> can be one of
 <listitem>
 <literal>reload</literal>&mdash;reload configuration,
 start the new worker process with a new configuration,
-gracefully shut down old worker processes.
+gracefully shut down old worker processes
 </listitem>
 <listitem>
 <literal>reopen</literal>&mdash;reopen log files
diff --git a/xml/ru/docs/switches.xml b/xml/ru/docs/switches.xml
--- a/xml/ru/docs/switches.xml
+++ b/xml/ru/docs/switches.xml
@@ -8,7 +8,7 @@
 <article name="????????? ????????? ?????? nginx"
          link="/ru/docs/switches.html"
          lang="ru"
-         rev="4">
+         rev="5">
 
 <section>
 
@@ -67,7 +67,7 @@ nginx -g "pid /var/run/nginx.pid; worker
 <listitem>
 <literal>reload</literal>&mdash;???????????? ????????????,
 ????? ?????? ???????? ???????? ? ????? ?????????????,
-??????? ?????????? ?????? ??????? ?????????.
+??????? ?????????? ?????? ??????? ?????????
 </listitem>
 <listitem>
 <literal>reopen</literal>&mdash;???????????? ???-??????

From mdounin at mdounin.ru  Tue Feb  3 13:23:32 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 3 Feb 2026 16:23:32 +0300
Subject: [PATCH] Fixed order of perl request object methods
In-Reply-To: <d83d66357a77d374475c.1770061342@mp2.macomnet.net>
References: <6589496596a1a7c180c6.1770044358@mp2.macomnet.net>
 <d83d66357a77d374475c.1770061342@mp2.macomnet.net>
Message-ID: <aYH21ICVpfr2ZO0U@mdounin.ru>

Hello!

On Mon, Feb 02, 2026 at 10:42:22PM +0300, Sergey A. Osokin wrote:

> # HG changeset patch
> # User Sergey A. Osokin <osa at FreeBSD.org.ru>
> # Date 1770061280 -10800
> #      Mon Feb 02 22:41:20 2026 +0300
> # Node ID d83d66357a77d374475c9db75b5487b68a380178
> # Parent  c6cbc552bd6a56e79276518253637c71628cbe16
> Fixed order of perl request object methods.

[...]

Committed, thanks.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Tue Feb  3 13:24:42 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 3 Feb 2026 16:24:42 +0300
Subject: [PATCH] Removed a needless dot symbol
In-Reply-To: <64e0cb07799425665623.1770056787@mp2.macomnet.net>
References: <6305a5da802e70da9d6c.1770054963@mp2.macomnet.net>
 <64e0cb07799425665623.1770056787@mp2.macomnet.net>
Message-ID: <aYH3Guf3LUzKkLZd@mdounin.ru>

Hello!

On Mon, Feb 02, 2026 at 09:26:27PM +0300, Sergey A. Osokin wrote:

> # HG changeset patch
> # User Sergey A. Osokin <osa at FreeBSD.org.ru>
> # Date 1770056711 -10800
> #      Mon Feb 02 21:25:11 2026 +0300
> # Node ID 64e0cb077994256656236f008924337e1c12dd4e
> # Parent  c6cbc552bd6a56e79276518253637c71628cbe16
> Removed a needless dot symbol.
> 
> diff -r c6cbc552bd6a -r 64e0cb077994 xml/en/docs/switches.xml
> --- a/xml/en/docs/switches.xml	Tue Dec 16 16:20:31 2025 +0300
> +++ b/xml/en/docs/switches.xml	Mon Feb 02 21:25:11 2026 +0300
> @@ -67,7 +67,7 @@
>  <listitem>
>  <literal>reload</literal>&mdash;reload configuration,
>  start the new worker process with a new configuration,
> -gracefully shut down old worker processes.
> +gracefully shut down old worker processes
>  </listitem>
>  <listitem>
>  <literal>reopen</literal>&mdash;reopen log files

Committed (with a Russian language counterpart), thanks.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Thu Feb  5 12:39:32 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Thu, 05 Feb 2026 15:39:32 +0300
Subject: [PATCH] Removed NGX_COMPAT_BEGIN and NGX_COMPAT_END macros
Message-ID: <1fef7bf265f0cd00046d.1770295172@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1770127023 -10800
#      Tue Feb 03 16:57:03 2026 +0300
# Node ID 1fef7bf265f0cd00046d684d9f503f8394051c3b
# Parent  d6723d4c4b8136b96cd42481bb33a165ddb87a05
Removed NGX_COMPAT_BEGIN and NGX_COMPAT_END macros.

These are only needed for compatibility with legacy code in closed-source
NGINX Plus, and now there are no reasons to keep these compatibility shims.

diff --git a/src/core/ngx_config.h b/src/core/ngx_config.h
--- a/src/core/ngx_config.h
+++ b/src/core/ngx_config.h
@@ -129,17 +129,4 @@ typedef intptr_t        ngx_flag_t;
 #define NGX_MAX_INT32_VALUE   (uint32_t) 0x7fffffff
 
 
-#if (NGX_COMPAT)
-
-#define NGX_COMPAT_BEGIN(slots)  uint64_t spare[slots];
-#define NGX_COMPAT_END
-
-#else
-
-#define NGX_COMPAT_BEGIN(slots)
-#define NGX_COMPAT_END
-
-#endif
-
-
 #endif /* _NGX_CONFIG_H_INCLUDED_ */
diff --git a/src/event/ngx_event_connect.h b/src/event/ngx_event_connect.h
--- a/src/event/ngx_event_connect.h
+++ b/src/event/ngx_event_connect.h
@@ -67,9 +67,6 @@ struct ngx_peer_connection_s {
 
                                      /* ngx_connection_log_error_e */
     unsigned                         log_error:2;
-
-    NGX_COMPAT_BEGIN(2)
-    NGX_COMPAT_END
 };
 
 
diff --git a/src/http/ngx_http_upstream.h b/src/http/ngx_http_upstream.h
--- a/src/http/ngx_http_upstream.h
+++ b/src/http/ngx_http_upstream.h
@@ -104,9 +104,6 @@ typedef struct {
     ngx_uint_t                       down;
 
     unsigned                         backup:1;
-
-    NGX_COMPAT_BEGIN(6)
-    NGX_COMPAT_END
 } ngx_http_upstream_server_t;
 
 
@@ -243,9 +240,6 @@ typedef struct {
 #endif
 
     ngx_str_t                        module;
-
-    NGX_COMPAT_BEGIN(2)
-    NGX_COMPAT_END
 } ngx_http_upstream_conf_t;
 
 
diff --git a/src/http/ngx_http_upstream_round_robin.h b/src/http/ngx_http_upstream_round_robin.h
--- a/src/http/ngx_http_upstream_round_robin.h
+++ b/src/http/ngx_http_upstream_round_robin.h
@@ -50,9 +50,6 @@ struct ngx_http_upstream_rr_peer_s {
 #endif
 
     ngx_http_upstream_rr_peer_t    *next;
-
-    NGX_COMPAT_BEGIN(32)
-    NGX_COMPAT_END
 };
 
 
diff --git a/src/stream/ngx_stream_upstream.h b/src/stream/ngx_stream_upstream.h
--- a/src/stream/ngx_stream_upstream.h
+++ b/src/stream/ngx_stream_upstream.h
@@ -61,9 +61,6 @@ typedef struct {
     ngx_uint_t                         down;
 
     unsigned                           backup:1;
-
-    NGX_COMPAT_BEGIN(4)
-    NGX_COMPAT_END
 } ngx_stream_upstream_server_t;
 
 
diff --git a/src/stream/ngx_stream_upstream_round_robin.h b/src/stream/ngx_stream_upstream_round_robin.h
--- a/src/stream/ngx_stream_upstream_round_robin.h
+++ b/src/stream/ngx_stream_upstream_round_robin.h
@@ -48,9 +48,6 @@ struct ngx_stream_upstream_rr_peer_s {
 #endif
 
     ngx_stream_upstream_rr_peer_t   *next;
-
-    NGX_COMPAT_BEGIN(25)
-    NGX_COMPAT_END
 };
 
 


From osa at FreeBSD.org.ru  Thu Feb  5 19:25:50 2026
From: osa at FreeBSD.org.ru (=?iso-8859-1?q?Sergey_A=2E_Osokin?=)
Date: Thu, 05 Feb 2026 22:25:50 +0300
Subject: [PATCH] Updated OpenSSL used for win32 builds
Message-ID: <aa4ed2bdbb5f23bb932f.1770319550@mp2.macomnet.net>

# HG changeset patch
# User Sergey A. Osokin <osa at FreeBSD.org.ru>
# Date 1770319450 -10800
#      Thu Feb 05 22:24:10 2026 +0300
# Node ID aa4ed2bdbb5f23bb932f1f2ef20db6d03b647f07
# Parent  d6723d4c4b8136b96cd42481bb33a165ddb87a05
Updated OpenSSL used for win32 builds.

diff -r d6723d4c4b81 -r aa4ed2bdbb5f misc/GNUmakefile
--- a/misc/GNUmakefile	Sat Jan 31 09:27:12 2026 +0300
+++ b/misc/GNUmakefile	Thu Feb 05 22:24:10 2026 +0300
@@ -6,7 +6,7 @@
 
 CC =		cl
 OBJS =		objs.msvc8
-OPENSSL =	openssl-3.0.18
+OPENSSL =	openssl-3.0.19
 ZLIB =		zlib-1.3.1
 PCRE =		pcre2-10.47
 

From mdounin at mdounin.ru  Sun Feb  8 13:14:26 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Sun, 08 Feb 2026 16:14:26 +0300
Subject: [nginx] Removed NGX_COMPAT_BEGIN and NGX_COMPAT_END macros.
Message-ID: <hg.1fef7bf265f0.1770556466.2122418885912679258@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/1fef7bf265f0
branches:  
changeset: 9463:1fef7bf265f0
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Feb 03 16:57:03 2026 +0300
description:
Removed NGX_COMPAT_BEGIN and NGX_COMPAT_END macros.

These are only needed for compatibility with legacy code in closed-source
NGINX Plus, and now there are no reasons to keep these compatibility shims.

diffstat:

 src/core/ngx_config.h                        |  13 -------------
 src/event/ngx_event_connect.h                |   3 ---
 src/http/ngx_http_upstream.h                 |   6 ------
 src/http/ngx_http_upstream_round_robin.h     |   3 ---
 src/stream/ngx_stream_upstream.h             |   3 ---
 src/stream/ngx_stream_upstream_round_robin.h |   3 ---
 6 files changed, 0 insertions(+), 31 deletions(-)

diffs (96 lines):

diff --git a/src/core/ngx_config.h b/src/core/ngx_config.h
--- a/src/core/ngx_config.h
+++ b/src/core/ngx_config.h
@@ -129,17 +129,4 @@ typedef intptr_t        ngx_flag_t;
 #define NGX_MAX_INT32_VALUE   (uint32_t) 0x7fffffff
 
 
-#if (NGX_COMPAT)
-
-#define NGX_COMPAT_BEGIN(slots)  uint64_t spare[slots];
-#define NGX_COMPAT_END
-
-#else
-
-#define NGX_COMPAT_BEGIN(slots)
-#define NGX_COMPAT_END
-
-#endif
-
-
 #endif /* _NGX_CONFIG_H_INCLUDED_ */
diff --git a/src/event/ngx_event_connect.h b/src/event/ngx_event_connect.h
--- a/src/event/ngx_event_connect.h
+++ b/src/event/ngx_event_connect.h
@@ -67,9 +67,6 @@ struct ngx_peer_connection_s {
 
                                      /* ngx_connection_log_error_e */
     unsigned                         log_error:2;
-
-    NGX_COMPAT_BEGIN(2)
-    NGX_COMPAT_END
 };
 
 
diff --git a/src/http/ngx_http_upstream.h b/src/http/ngx_http_upstream.h
--- a/src/http/ngx_http_upstream.h
+++ b/src/http/ngx_http_upstream.h
@@ -104,9 +104,6 @@ typedef struct {
     ngx_uint_t                       down;
 
     unsigned                         backup:1;
-
-    NGX_COMPAT_BEGIN(6)
-    NGX_COMPAT_END
 } ngx_http_upstream_server_t;
 
 
@@ -243,9 +240,6 @@ typedef struct {
 #endif
 
     ngx_str_t                        module;
-
-    NGX_COMPAT_BEGIN(2)
-    NGX_COMPAT_END
 } ngx_http_upstream_conf_t;
 
 
diff --git a/src/http/ngx_http_upstream_round_robin.h b/src/http/ngx_http_upstream_round_robin.h
--- a/src/http/ngx_http_upstream_round_robin.h
+++ b/src/http/ngx_http_upstream_round_robin.h
@@ -50,9 +50,6 @@ struct ngx_http_upstream_rr_peer_s {
 #endif
 
     ngx_http_upstream_rr_peer_t    *next;
-
-    NGX_COMPAT_BEGIN(32)
-    NGX_COMPAT_END
 };
 
 
diff --git a/src/stream/ngx_stream_upstream.h b/src/stream/ngx_stream_upstream.h
--- a/src/stream/ngx_stream_upstream.h
+++ b/src/stream/ngx_stream_upstream.h
@@ -61,9 +61,6 @@ typedef struct {
     ngx_uint_t                         down;
 
     unsigned                           backup:1;
-
-    NGX_COMPAT_BEGIN(4)
-    NGX_COMPAT_END
 } ngx_stream_upstream_server_t;
 
 
diff --git a/src/stream/ngx_stream_upstream_round_robin.h b/src/stream/ngx_stream_upstream_round_robin.h
--- a/src/stream/ngx_stream_upstream_round_robin.h
+++ b/src/stream/ngx_stream_upstream_round_robin.h
@@ -48,9 +48,6 @@ struct ngx_stream_upstream_rr_peer_s {
 #endif
 
     ngx_stream_upstream_rr_peer_t   *next;
-
-    NGX_COMPAT_BEGIN(25)
-    NGX_COMPAT_END
 };
 
 

From mdounin at mdounin.ru  Sun Feb  8 13:14:26 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Sun, 08 Feb 2026 16:14:26 +0300
Subject: [nginx] Updated OpenSSL used for win32 builds.
Message-ID: <hg.b44cd6f3bc98.1770556466.2122418885912679258@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/b44cd6f3bc98
branches:  
changeset: 9464:b44cd6f3bc98
user:      Sergey A. Osokin <osa at FreeBSD.org.ru>
date:      Thu Feb 05 22:24:10 2026 +0300
description:
Updated OpenSSL used for win32 builds.

diffstat:

 misc/GNUmakefile |  2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diffs (12 lines):

diff --git a/misc/GNUmakefile b/misc/GNUmakefile
--- a/misc/GNUmakefile
+++ b/misc/GNUmakefile
@@ -6,7 +6,7 @@ TEMP =		tmp
 
 CC =		cl
 OBJS =		objs.msvc8
-OPENSSL =	openssl-3.0.18
+OPENSSL =	openssl-3.0.19
 ZLIB =		zlib-1.3.1
 PCRE =		pcre2-10.47
 

From mdounin at mdounin.ru  Sun Feb  8 13:14:51 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 8 Feb 2026 16:14:51 +0300
Subject: [PATCH] Updated OpenSSL used for win32 builds
In-Reply-To: <aa4ed2bdbb5f23bb932f.1770319550@mp2.macomnet.net>
References: <aa4ed2bdbb5f23bb932f.1770319550@mp2.macomnet.net>
Message-ID: <aYiMS2w0KnrFDGdS@mdounin.ru>

Hello!

On Thu, Feb 05, 2026 at 10:25:50PM +0300, Sergey A. Osokin wrote:

> # HG changeset patch
> # User Sergey A. Osokin <osa at FreeBSD.org.ru>
> # Date 1770319450 -10800
> #      Thu Feb 05 22:24:10 2026 +0300
> # Node ID aa4ed2bdbb5f23bb932f1f2ef20db6d03b647f07
> # Parent  d6723d4c4b8136b96cd42481bb33a165ddb87a05
> Updated OpenSSL used for win32 builds.
> 
> diff -r d6723d4c4b81 -r aa4ed2bdbb5f misc/GNUmakefile
> --- a/misc/GNUmakefile	Sat Jan 31 09:27:12 2026 +0300
> +++ b/misc/GNUmakefile	Thu Feb 05 22:24:10 2026 +0300
> @@ -6,7 +6,7 @@
>  
>  CC =		cl
>  OBJS =		objs.msvc8
> -OPENSSL =	openssl-3.0.18
> +OPENSSL =	openssl-3.0.19
>  ZLIB =		zlib-1.3.1
>  PCRE =		pcre2-10.47
>  

Committed, thanks.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Sun Feb  8 20:23:13 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Sun, 08 Feb 2026 23:23:13 +0300
Subject: [PATCH] Upstream: fixed SSL initialization on read events
Message-ID: <bce5954f74a115503fd2.1770582193@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1770581815 -10800
#      Sun Feb 08 23:16:55 2026 +0300
# Node ID bce5954f74a115503fd22d955d0fcea18f6c77cb
# Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
Upstream: fixed SSL initialization on read events.

Previously, SSL initialization only happened on write events, which are
reported once a TCP connection is established.  However, if some data
are received before the write event is reported, the read event might be
reported first, potentially resulting in a plain text response being
accepted when it shouldn't (CVE-2026-1642).

Normally SSL servers do not send anything before ClientHello from the
client, though formally they are allowed to (for example, HelloRequest
messages may be sent at any time).  As such, the fix is to do proper SSL
initialization on read events as well.  This ensures correct and identical
behaviour regardless of the order of events being reported.

diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
--- a/src/http/ngx_http_upstream.c
+++ b/src/http/ngx_http_upstream.c
@@ -2442,6 +2442,15 @@ ngx_http_upstream_process_header(ngx_htt
         return;
     }
 
+#if (NGX_HTTP_SSL)
+
+    if (u->ssl && c->ssl == NULL) {
+        ngx_http_upstream_ssl_init_connection(r, u, c);
+        return;
+    }
+
+#endif
+
     if (u->buffer.start == NULL) {
         u->buffer.start = ngx_palloc(r->pool, u->conf->buffer_size);
         if (u->buffer.start == NULL) {


From vl at inspert.ru  Mon Feb  9 13:58:34 2026
From: vl at inspert.ru (Vladimir Homutov)
Date: Mon, 9 Feb 2026 16:58:34 +0300
Subject: [PATCH] Upstream: fixed SSL initialization on read events
In-Reply-To: <bce5954f74a115503fd2.1770582193@vm-bsd.mdounin.ru>
References: <bce5954f74a115503fd2.1770582193@vm-bsd.mdounin.ru>
Message-ID: <aYnoCsiUmAq9Rj0U@vl.krasnogorsk.ru>

On Sun, Feb 08, 2026 at 11:23:13PM +0300, Maxim Dounin wrote:
> # HG changeset patch
> # User Maxim Dounin <mdounin at mdounin.ru>
> # Date 1770581815 -10800
> #      Sun Feb 08 23:16:55 2026 +0300
> # Node ID bce5954f74a115503fd22d955d0fcea18f6c77cb
> # Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
> Upstream: fixed SSL initialization on read events.
>
> Previously, SSL initialization only happened on write events, which are
> reported once a TCP connection is established.  However, if some data
> are received before the write event is reported, the read event might be
> reported first, potentially resulting in a plain text response being
> accepted when it shouldn't (CVE-2026-1642).
>
> Normally SSL servers do not send anything before ClientHello from the
> client, though formally they are allowed to (for example, HelloRequest
> messages may be sent at any time).  As such, the fix is to do proper SSL
> initialization on read events as well.  This ensures correct and identical
> behaviour regardless of the order of events being reported.

Hello,

while the fix does the job, I think that the root reason
is the fact that we set u->read_event_handler to ngx_http_upstream_process_header
in ngx_http_upstream_connect(), when we haven't yet sent the request.

And we have no idea what the request will be (maybe plaintext, maybe
SSL, maybe some other protocol).

It looks like the reasonable default for u->read_event_handler should be
setting something like 'reject_premature_response'.

And when we later connect and send the request, we may override it with
appropriate handlers according to the desired protocol.


From mdounin at mdounin.ru  Tue Feb 10 02:56:15 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Feb 2026 05:56:15 +0300
Subject: [PATCH] Upstream: fixed SSL initialization on read events
In-Reply-To: <aYnoCsiUmAq9Rj0U@vl.krasnogorsk.ru>
References: <bce5954f74a115503fd2.1770582193@vm-bsd.mdounin.ru>
 <aYnoCsiUmAq9Rj0U@vl.krasnogorsk.ru>
Message-ID: <aYqeT1cc7WgfhitY@mdounin.ru>

Hello!

On Mon, Feb 09, 2026 at 04:58:34PM +0300, Vladimir Homutov via nginx-devel wrote:

> On Sun, Feb 08, 2026 at 11:23:13PM +0300, Maxim Dounin wrote:
> > # HG changeset patch
> > # User Maxim Dounin <mdounin at mdounin.ru>
> > # Date 1770581815 -10800
> > #      Sun Feb 08 23:16:55 2026 +0300
> > # Node ID bce5954f74a115503fd22d955d0fcea18f6c77cb
> > # Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
> > Upstream: fixed SSL initialization on read events.
> >
> > Previously, SSL initialization only happened on write events, which are
> > reported once a TCP connection is established.  However, if some data
> > are received before the write event is reported, the read event might be
> > reported first, potentially resulting in a plain text response being
> > accepted when it shouldn't (CVE-2026-1642).
> >
> > Normally SSL servers do not send anything before ClientHello from the
> > client, though formally they are allowed to (for example, HelloRequest
> > messages may be sent at any time).  As such, the fix is to do proper SSL
> > initialization on read events as well.  This ensures correct and identical
> > behaviour regardless of the order of events being reported.
> 
> Hello,
> 
> while the fix does the job, I think that the root reason
> is the fact that we set u->read_event_handler to ngx_http_upstream_process_header
> in ngx_http_upstream_connect(), when we haven't yet sent the request.
> 
> And we have no idea what the request will be (maybe plaintext, maybe
> SSL, maybe some other protocol).
> 
> It looks like the reasonable default for u->read_event_handler should be
> setting something like 'reject_premature_response'.
> 
> And when we later connect and send the request, we may override it with
> appropriate handlers according to the desired protocol.

I don't think that rejecting premature responses is a correct 
approach, since at least in case of SSL server can legitimately 
send data first: as mentioned in the commit log, HelloRequest 
messages in TLSv1.2 may be sent at any time, see here:

https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.1

While it says that "Servers SHOULD NOT send a HelloRequest 
immediately upon the client's initial connection", servers still 
can send it, either immediately or after some timeout, and this is 
not expected to break things (but it will if we'll reject any 
data before the write handler is triggered).

Also I tend to think that in HTTP returning a response without an 
actual request on the wire is also valid - e.g., 408 might be 
returned due to a timeout before the request is received, or 503 
might be sent due to some server issues without trying to read an 
actual request.

What probably can be done here is a block reading handler, so 
reading will actually happen, but only after the write event 
handler is triggered (and we'll decide what to do with the 
connection).  It will indeed simplify things though, including 
fixing some other issues (notably proper reinitialization when 
switching to next upstream after a premature response, and
$upstream_connect_time calculation).

A downside of this approach is that it doesn't allow optimized 
handling of premature error responses.  On the other hand, it does 
not look like a big issue, as such responses aren't common (if 
exist at all).

The patch below implements this approach.  What do you think?

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1770691814 -10800
#      Tue Feb 10 05:50:14 2026 +0300
# Node ID 36c9c3fae57f47a5a6710cc754e52f79ae8dc0fe
# Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
Upstream: blocked read events till sending request.

Previously, SSL initialization only happened on write events, which are
reported once a TCP connection is established.  However, if some data
are received before the write event is reported, the read event might be
reported first, potentially resulting in a plain text response being
accepted when it shouldn't (CVE-2026-1642).

Similarly, if a response was received before the write event was reported
(and hence before the request was sent to the upstream server), switching
to the next upstream server failed to do proper reinitialization, which
used to check the u->request_sent flag.  This resulted in various issues,
most notably previously parsed headers were not cleared.

Normally SSL servers do not send anything before ClientHello from the
client, though formally they are allowed to (for example, HelloRequest
messages may be sent at any time).  Further, returning an immediate error
response might also be seen as valid, for example, in HTTP.  As such,
the fix is to block read events until the write event is reported, ensuring
correct and identical behaviour regardless of the order of events being
reported.

diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
--- a/src/http/ngx_http_upstream.c
+++ b/src/http/ngx_http_upstream.c
@@ -52,6 +52,8 @@ static ngx_int_t ngx_http_upstream_send_
 static void ngx_http_upstream_send_request_handler(ngx_http_request_t *r,
     ngx_http_upstream_t *u);
 static void ngx_http_upstream_read_request_handler(ngx_http_request_t *r);
+static void ngx_http_upstream_block_reading(ngx_http_request_t *r,
+    ngx_http_upstream_t *u);
 static void ngx_http_upstream_process_header(ngx_http_request_t *r,
     ngx_http_upstream_t *u);
 static ngx_int_t ngx_http_upstream_test_next(ngx_http_request_t *r,
@@ -1595,7 +1597,7 @@ ngx_http_upstream_connect(ngx_http_reque
     c->read->handler = ngx_http_upstream_handler;
 
     u->write_event_handler = ngx_http_upstream_send_request_handler;
-    u->read_event_handler = ngx_http_upstream_process_header;
+    u->read_event_handler = ngx_http_upstream_block_reading;
 
     c->sendfile &= r->connection->sendfile;
     u->output.sendfile = c->sendfile;
@@ -2138,6 +2140,10 @@ ngx_http_upstream_send_request(ngx_http_
         return;
     }
 
+    if (!u->request_sent) {
+        u->read_event_handler = ngx_http_upstream_process_header;
+    }
+
     sent = c->sent;
 
     if (!u->request_sent) {
@@ -2419,6 +2425,24 @@ ngx_http_upstream_read_request_handler(n
 
 
 static void
+ngx_http_upstream_block_reading(ngx_http_request_t *r, ngx_http_upstream_t *u)
+{
+    ngx_connection_t  *c;
+
+    c = u->peer.connection;
+
+    ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0,
+                   "http upstream block reading");
+
+    if (ngx_handle_read_event(c->read, 0) != NGX_OK) {
+        ngx_http_upstream_finalize_request(r, u,
+                                           NGX_HTTP_INTERNAL_SERVER_ERROR);
+        return;
+    }
+}
+
+
+static void
 ngx_http_upstream_process_header(ngx_http_request_t *r, ngx_http_upstream_t *u)
 {
     ssize_t            n;
@@ -2437,11 +2461,6 @@ ngx_http_upstream_process_header(ngx_htt
         return;
     }
 
-    if (!u->request_sent && ngx_http_upstream_test_connect(c) != NGX_OK) {
-        ngx_http_upstream_next(r, u, NGX_HTTP_UPSTREAM_FT_ERROR);
-        return;
-    }
-
     if (u->buffer.start == NULL) {
         u->buffer.start = ngx_palloc(r->pool, u->conf->buffer_size);
         if (u->buffer.start == NULL) {

-- 
Maxim Dounin
http://mdounin.ru/

From vl at inspert.ru  Tue Feb 10 09:49:49 2026
From: vl at inspert.ru (Vladimir Homutov)
Date: Tue, 10 Feb 2026 12:49:49 +0300
Subject: [PATCH] Upstream: fixed SSL initialization on read events
In-Reply-To: <aYqeT1cc7WgfhitY@mdounin.ru>
References: <bce5954f74a115503fd2.1770582193@vm-bsd.mdounin.ru>
 <aYnoCsiUmAq9Rj0U@vl.krasnogorsk.ru> <aYqeT1cc7WgfhitY@mdounin.ru>
Message-ID: <aYr_PaIOXSqwNuLe@vl.krasnogorsk.ru>

On Tue, Feb 10, 2026 at 05:56:15AM +0300, Maxim Dounin wrote:
> Hello!
>
> On Mon, Feb 09, 2026 at 04:58:34PM +0300, Vladimir Homutov via nginx-devel wrote:
>
> > On Sun, Feb 08, 2026 at 11:23:13PM +0300, Maxim Dounin wrote:
> > > # HG changeset patch
> > > # User Maxim Dounin <mdounin at mdounin.ru>
> > > # Date 1770581815 -10800
> > > #      Sun Feb 08 23:16:55 2026 +0300
> > > # Node ID bce5954f74a115503fd22d955d0fcea18f6c77cb
> > > # Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
> > > Upstream: fixed SSL initialization on read events.
> > >
> > > Previously, SSL initialization only happened on write events, which are
> > > reported once a TCP connection is established.  However, if some data
> > > are received before the write event is reported, the read event might be
> > > reported first, potentially resulting in a plain text response being
> > > accepted when it shouldn't (CVE-2026-1642).
> > >
> > > Normally SSL servers do not send anything before ClientHello from the
> > > client, though formally they are allowed to (for example, HelloRequest
> > > messages may be sent at any time).  As such, the fix is to do proper SSL
> > > initialization on read events as well.  This ensures correct and identical
> > > behaviour regardless of the order of events being reported.
> >
> > Hello,
> >
> > while the fix does the job, I think that the root reason
> > is the fact that we set u->read_event_handler to ngx_http_upstream_process_header
> > in ngx_http_upstream_connect(), when we haven't yet sent the request.
> >
> > And we have no idea what the request will be (maybe plaintext, maybe
> > SSL, maybe some other protocol).
> >
> > It looks like the reasonable default for u->read_event_handler should be
> > setting something like 'reject_premature_response'.
> >
> > And when we later connect and send the request, we may override it with
> > appropriate handlers according to the desired protocol.
>
> I don't think that rejecting premature responses is a correct
> approach, since at least in case of SSL server can legitimately
> send data first: as mentioned in the commit log, HelloRequest
> messages in TLSv1.2 may be sent at any time, see here:
>
> https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.1
>
> While it says that "Servers SHOULD NOT send a HelloRequest
> immediately upon the client's initial connection", servers still
> can send it, either immediately or after some timeout, and this is
> not expected to break things (but it will if we'll reject any
> data before the write handler is triggered).
>
> Also I tend to think that in HTTP returning a response without an
> actual request on the wire is also valid - e.g., 408 might be
> returned due to a timeout before the request is received, or 503
> might be sent due to some server issues without trying to read an
> actual request.
>
> What probably can be done here is a block reading handler, so
> reading will actually happen, but only after the write event
> handler is triggered (and we'll decide what to do with the
> connection).  It will indeed simplify things though, including
> fixing some other issues (notably proper reinitialization when
> switching to next upstream after a premature response, and
> $upstream_connect_time calculation).
>
> A downside of this approach is that it doesn't allow optimized
> handling of premature error responses.  On the other hand, it does
> not look like a big issue, as such responses aren't common (if
> exist at all).
>
> The patch below implements this approach.  What do you think?
>
> # HG changeset patch
> # User Maxim Dounin <mdounin at mdounin.ru>
> # Date 1770691814 -10800
> #      Tue Feb 10 05:50:14 2026 +0300
> # Node ID 36c9c3fae57f47a5a6710cc754e52f79ae8dc0fe
> # Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
> Upstream: blocked read events till sending request.
>
> Previously, SSL initialization only happened on write events, which are
> reported once a TCP connection is established.  However, if some data
> are received before the write event is reported, the read event might be
> reported first, potentially resulting in a plain text response being
> accepted when it shouldn't (CVE-2026-1642).
>
> Similarly, if a response was received before the write event was reported
> (and hence before the request was sent to the upstream server), switching
> to the next upstream server failed to do proper reinitialization, which
> used to check the u->request_sent flag.  This resulted in various issues,
> most notably previously parsed headers were not cleared.
>
> Normally SSL servers do not send anything before ClientHello from the
> client, though formally they are allowed to (for example, HelloRequest
> messages may be sent at any time).  Further, returning an immediate error
> response might also be seen as valid, for example, in HTTP.  As such,
> the fix is to block read events until the write event is reported, ensuring
> correct and identical behaviour regardless of the order of events being
> reported.
>
> diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
> --- a/src/http/ngx_http_upstream.c
> +++ b/src/http/ngx_http_upstream.c
> @@ -52,6 +52,8 @@ static ngx_int_t ngx_http_upstream_send_
>  static void ngx_http_upstream_send_request_handler(ngx_http_request_t *r,
>      ngx_http_upstream_t *u);
>  static void ngx_http_upstream_read_request_handler(ngx_http_request_t *r);
> +static void ngx_http_upstream_block_reading(ngx_http_request_t *r,
> +    ngx_http_upstream_t *u);
>  static void ngx_http_upstream_process_header(ngx_http_request_t *r,
>      ngx_http_upstream_t *u);
>  static ngx_int_t ngx_http_upstream_test_next(ngx_http_request_t *r,
> @@ -1595,7 +1597,7 @@ ngx_http_upstream_connect(ngx_http_reque
>      c->read->handler = ngx_http_upstream_handler;
>
>      u->write_event_handler = ngx_http_upstream_send_request_handler;
> -    u->read_event_handler = ngx_http_upstream_process_header;
> +    u->read_event_handler = ngx_http_upstream_block_reading;
>
>      c->sendfile &= r->connection->sendfile;
>      u->output.sendfile = c->sendfile;
> @@ -2138,6 +2140,10 @@ ngx_http_upstream_send_request(ngx_http_
>          return;
>      }
>
> +    if (!u->request_sent) {
> +        u->read_event_handler = ngx_http_upstream_process_header;
> +    }
> +
>      sent = c->sent;
>
>      if (!u->request_sent) {
> @@ -2419,6 +2425,24 @@ ngx_http_upstream_read_request_handler(n
>
>
>  static void
> +ngx_http_upstream_block_reading(ngx_http_request_t *r, ngx_http_upstream_t *u)
> +{
> +    ngx_connection_t  *c;
> +
> +    c = u->peer.connection;
> +
> +    ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0,
> +                   "http upstream block reading");
> +
> +    if (ngx_handle_read_event(c->read, 0) != NGX_OK) {
> +        ngx_http_upstream_finalize_request(r, u,
> +                                           NGX_HTTP_INTERNAL_SERVER_ERROR);
> +        return;
> +    }
> +}
> +
> +
> +static void
>  ngx_http_upstream_process_header(ngx_http_request_t *r, ngx_http_upstream_t *u)
>  {
>      ssize_t            n;
> @@ -2437,11 +2461,6 @@ ngx_http_upstream_process_header(ngx_htt
>          return;
>      }
>
> -    if (!u->request_sent && ngx_http_upstream_test_connect(c) != NGX_OK) {
> -        ngx_http_upstream_next(r, u, NGX_HTTP_UPSTREAM_FT_ERROR);
> -        return;
> -    }
> -
>      if (u->buffer.start == NULL) {
>          u->buffer.start = ngx_palloc(r->pool, u->conf->buffer_size);
>          if (u->buffer.start == NULL) {
>

yes, this makes sense.

looks good for me.

From mdounin at mdounin.ru  Tue Feb 10 11:17:23 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 10 Feb 2026 14:17:23 +0300
Subject: [nginx] Upstream: blocked read events till sending request.
Message-ID: <hg.36c9c3fae57f.1770722243.-7789061576446703369@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/36c9c3fae57f
branches:  
changeset: 9465:36c9c3fae57f
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Feb 10 05:50:14 2026 +0300
description:
Upstream: blocked read events till sending request.

Previously, SSL initialization only happened on write events, which are
reported once a TCP connection is established.  However, if some data
are received before the write event is reported, the read event might be
reported first, potentially resulting in a plain text response being
accepted when it shouldn't (CVE-2026-1642).

Similarly, if a response was received before the write event was reported
(and hence before the request was sent to the upstream server), switching
to the next upstream server failed to do proper reinitialization, which
used to check the u->request_sent flag.  This resulted in various issues,
most notably previously parsed headers were not cleared.

Normally SSL servers do not send anything before ClientHello from the
client, though formally they are allowed to (for example, HelloRequest
messages may be sent at any time).  Further, returning an immediate error
response might also be seen as valid, for example, in HTTP.  As such,
the fix is to block read events until the write event is reported, ensuring
correct and identical behaviour regardless of the order of events being
reported.

diffstat:

 src/http/ngx_http_upstream.c |  31 +++++++++++++++++++++++++------
 1 files changed, 25 insertions(+), 6 deletions(-)

diffs (69 lines):

diff --git a/src/http/ngx_http_upstream.c b/src/http/ngx_http_upstream.c
--- a/src/http/ngx_http_upstream.c
+++ b/src/http/ngx_http_upstream.c
@@ -52,6 +52,8 @@ static ngx_int_t ngx_http_upstream_send_
 static void ngx_http_upstream_send_request_handler(ngx_http_request_t *r,
     ngx_http_upstream_t *u);
 static void ngx_http_upstream_read_request_handler(ngx_http_request_t *r);
+static void ngx_http_upstream_block_reading(ngx_http_request_t *r,
+    ngx_http_upstream_t *u);
 static void ngx_http_upstream_process_header(ngx_http_request_t *r,
     ngx_http_upstream_t *u);
 static ngx_int_t ngx_http_upstream_test_next(ngx_http_request_t *r,
@@ -1595,7 +1597,7 @@ ngx_http_upstream_connect(ngx_http_reque
     c->read->handler = ngx_http_upstream_handler;
 
     u->write_event_handler = ngx_http_upstream_send_request_handler;
-    u->read_event_handler = ngx_http_upstream_process_header;
+    u->read_event_handler = ngx_http_upstream_block_reading;
 
     c->sendfile &= r->connection->sendfile;
     u->output.sendfile = c->sendfile;
@@ -2138,6 +2140,10 @@ ngx_http_upstream_send_request(ngx_http_
         return;
     }
 
+    if (!u->request_sent) {
+        u->read_event_handler = ngx_http_upstream_process_header;
+    }
+
     sent = c->sent;
 
     if (!u->request_sent) {
@@ -2419,6 +2425,24 @@ ngx_http_upstream_read_request_handler(n
 
 
 static void
+ngx_http_upstream_block_reading(ngx_http_request_t *r, ngx_http_upstream_t *u)
+{
+    ngx_connection_t  *c;
+
+    c = u->peer.connection;
+
+    ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0,
+                   "http upstream block reading");
+
+    if (ngx_handle_read_event(c->read, 0) != NGX_OK) {
+        ngx_http_upstream_finalize_request(r, u,
+                                           NGX_HTTP_INTERNAL_SERVER_ERROR);
+        return;
+    }
+}
+
+
+static void
 ngx_http_upstream_process_header(ngx_http_request_t *r, ngx_http_upstream_t *u)
 {
     ssize_t            n;
@@ -2437,11 +2461,6 @@ ngx_http_upstream_process_header(ngx_htt
         return;
     }
 
-    if (!u->request_sent && ngx_http_upstream_test_connect(c) != NGX_OK) {
-        ngx_http_upstream_next(r, u, NGX_HTTP_UPSTREAM_FT_ERROR);
-        return;
-    }
-
     if (u->buffer.start == NULL) {
         u->buffer.start = ngx_palloc(r->pool, u->conf->buffer_size);
         if (u->buffer.start == NULL) {

From mdounin at mdounin.ru  Tue Feb 10 11:19:00 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Feb 2026 14:19:00 +0300
Subject: [PATCH] Upstream: fixed SSL initialization on read events
In-Reply-To: <aYr_PaIOXSqwNuLe@vl.krasnogorsk.ru>
References: <bce5954f74a115503fd2.1770582193@vm-bsd.mdounin.ru>
 <aYnoCsiUmAq9Rj0U@vl.krasnogorsk.ru> <aYqeT1cc7WgfhitY@mdounin.ru>
 <aYr_PaIOXSqwNuLe@vl.krasnogorsk.ru>
Message-ID: <aYsUJM20C19TSLWN@mdounin.ru>

Hello!

On Tue, Feb 10, 2026 at 12:49:49PM +0300, Vladimir Homutov via nginx-devel wrote:

> On Tue, Feb 10, 2026 at 05:56:15AM +0300, Maxim Dounin wrote:
> > Hello!
> >
> > On Mon, Feb 09, 2026 at 04:58:34PM +0300, Vladimir Homutov via nginx-devel wrote:
> >
> > > On Sun, Feb 08, 2026 at 11:23:13PM +0300, Maxim Dounin wrote:
> > > > # HG changeset patch
> > > > # User Maxim Dounin <mdounin at mdounin.ru>
> > > > # Date 1770581815 -10800
> > > > #      Sun Feb 08 23:16:55 2026 +0300
> > > > # Node ID bce5954f74a115503fd22d955d0fcea18f6c77cb
> > > > # Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
> > > > Upstream: fixed SSL initialization on read events.
> > > >
> > > > Previously, SSL initialization only happened on write events, which are
> > > > reported once a TCP connection is established.  However, if some data
> > > > are received before the write event is reported, the read event might be
> > > > reported first, potentially resulting in a plain text response being
> > > > accepted when it shouldn't (CVE-2026-1642).
> > > >
> > > > Normally SSL servers do not send anything before ClientHello from the
> > > > client, though formally they are allowed to (for example, HelloRequest
> > > > messages may be sent at any time).  As such, the fix is to do proper SSL
> > > > initialization on read events as well.  This ensures correct and identical
> > > > behaviour regardless of the order of events being reported.
> > >
> > > Hello,
> > >
> > > while the fix does the job, I think that the root reason
> > > is the fact that we set u->read_event_handler to ngx_http_upstream_process_header
> > > in ngx_http_upstream_connect(), when we haven't yet sent the request.
> > >
> > > And we have no idea what the request will be (maybe plaintext, maybe
> > > SSL, maybe some other protocol).
> > >
> > > It looks like the reasonable default for u->read_event_handler should be
> > > setting something like 'reject_premature_response'.
> > >
> > > And when we later connect and send the request, we may override it with
> > > appropriate handlers according to the desired protocol.
> >
> > I don't think that rejecting premature responses is a correct
> > approach, since at least in case of SSL server can legitimately
> > send data first: as mentioned in the commit log, HelloRequest
> > messages in TLSv1.2 may be sent at any time, see here:
> >
> > https://datatracker.ietf.org/doc/html/rfc5246#section-7.4.1.1
> >
> > While it says that "Servers SHOULD NOT send a HelloRequest
> > immediately upon the client's initial connection", servers still
> > can send it, either immediately or after some timeout, and this is
> > not expected to break things (but it will if we'll reject any
> > data before the write handler is triggered).
> >
> > Also I tend to think that in HTTP returning a response without an
> > actual request on the wire is also valid - e.g., 408 might be
> > returned due to a timeout before the request is received, or 503
> > might be sent due to some server issues without trying to read an
> > actual request.
> >
> > What probably can be done here is a block reading handler, so
> > reading will actually happen, but only after the write event
> > handler is triggered (and we'll decide what to do with the
> > connection).  It will indeed simplify things though, including
> > fixing some other issues (notably proper reinitialization when
> > switching to next upstream after a premature response, and
> > $upstream_connect_time calculation).
> >
> > A downside of this approach is that it doesn't allow optimized
> > handling of premature error responses.  On the other hand, it does
> > not look like a big issue, as such responses aren't common (if
> > exist at all).
> >
> > The patch below implements this approach.  What do you think?
> >
> > # HG changeset patch
> > # User Maxim Dounin <mdounin at mdounin.ru>
> > # Date 1770691814 -10800
> > #      Tue Feb 10 05:50:14 2026 +0300
> > # Node ID 36c9c3fae57f47a5a6710cc754e52f79ae8dc0fe
> > # Parent  b44cd6f3bc983859f3a213fbff19b4761ac59ec8
> > Upstream: blocked read events till sending request.

[...]

> yes, this makes sense.
> 
> looks good for me.

Committed, thanks for looking into it.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Tue Feb 10 12:08:58 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 10 Feb 2026 15:08:58 +0300
Subject: freenginx-1.29.5 changes draft
Message-ID: <aYsf2i5PE2uJz6kT@mdounin.ru>

Hello!


Changes with freenginx 1.29.5                                    10 Feb 2026

    *) Feature: optimized SSL_sendfile() usage on FreeBSD.
       Thanks to Gleb Smirnoff.

    *) Bugfix: upstream servers were not marked as failed after a response
       with status code 500, 502, 503, 504, or 429 if the code was listed in
       the "proxy_next_upstream" directive, but switching to the next server
       was not possible.

    *) Bugfix: the "stale-if-error" cache control extension was not applied
       if a backend returned a response with status code 500, 502, 503, 504,
       or 429 and the code was listed in the "proxy_next_upstream"
       directive.

    *) Bugfix: in handling of premature backend responses.


????????? ? freenginx 1.29.5                                      10.02.2026

    *) ??????????: ??????????? ????????????? SSL_sendfile() ?? FreeBSD.
       ??????? ????? ????????.

    *) ???????????: ??????? ?? ???????????? ????????????? ????? ?????????
       ?????? ? ????? 500, 502, 503, 504 ??? 429, ???? ??????????????? ???
       ??? ?????? ? ????????? proxy_next_upstream, ?? ???????? ??????? ??
       ?????? ?????? ???? ??????????.

    *) ???????????: ?????????? ?????????? ???????????? stale-if-error ??
       ???????????, ???? ?????? ????????? ????? ? ????? 500, 502, 503, 504
       ??? 429 ? ??????????????? ??? ??? ?????? ? ?????????
       proxy_next_upstream.

    *) ???????????: ? ????????? ??????????????? ??????? ????????.


-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Tue Feb 10 16:46:47 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 10 Feb 2026 19:46:47 +0300
Subject: [nginx] freenginx-1.29.5-RELEASE
Message-ID: <hg.4f4280557d20.1770742007.-7181220127259735002@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/4f4280557d20
branches:  
changeset: 9466:4f4280557d20
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Feb 10 19:39:39 2026 +0300
description:
freenginx-1.29.5-RELEASE

diffstat:

 docs/xml/nginx/changes.xml |  61 ++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 61 insertions(+), 0 deletions(-)

diffs (71 lines):

diff --git a/docs/xml/nginx/changes.xml b/docs/xml/nginx/changes.xml
--- a/docs/xml/nginx/changes.xml
+++ b/docs/xml/nginx/changes.xml
@@ -7,6 +7,67 @@
 <section title="freenginx">
 
 
+<changes ver="1.29.5" date="2026-02-10">
+
+<change type="feature">
+<para lang="ru">
+??????????? ????????????? SSL_sendfile() ?? FreeBSD.<br/>
+??????? ????? ????????.
+</para>
+<para lang="en">
+optimized SSL_sendfile() usage on FreeBSD.<br/>
+Thanks to Gleb Smirnoff.
+</para>
+</change>
+
+<change type="bugfix">
+<para lang="ru">
+??????? ?? ???????????? ?????????????
+????? ????????? ??????
+? ????? 500, 502, 503, 504 ??? 429,
+???? ??????????????? ??? ??? ??????
+? ????????? proxy_next_upstream,
+?? ???????? ??????? ?? ?????? ?????? ???? ??????????.
+</para>
+<para lang="en">
+upstream servers were not marked as failed
+after a response
+with status code 500, 502, 503, 504, or 429
+if the code was listed in
+the "proxy_next_upstream" directive,
+but switching to the next server was not possible.
+</para>
+</change>
+
+<change type="bugfix">
+<para lang="ru">
+?????????? ?????????? ???????????? stale-if-error ?? ???????????,
+???? ?????? ????????? ?????
+? ????? 500, 502, 503, 504 ??? 429
+? ??????????????? ??? ??? ??????
+? ????????? proxy_next_upstream.
+</para>
+<para lang="en">
+the "stale-if-error" cache control extension was not applied
+if a backend returned a response
+with status code 500, 502, 503, 504, or 429
+and the code was listed in
+the "proxy_next_upstream" directive.
+</para>
+</change>
+
+<change type="bugfix">
+<para lang="ru">
+? ????????? ??????????????? ??????? ????????.
+</para>
+<para lang="en">
+in handling of premature backend responses.
+</para>
+</change>
+
+</changes>
+
+
 <changes ver="1.29.4" date="2025-12-16">
 
 <change type="feature">

From mdounin at mdounin.ru  Tue Feb 10 16:46:48 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 10 Feb 2026 19:46:48 +0300
Subject: [nginx] release-1.29.5 tag
Message-ID: <hg.c5a5aa2658d7.1770742008.-7181220127259735002@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/c5a5aa2658d7
branches:  
changeset: 9467:c5a5aa2658d7
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Feb 10 19:39:40 2026 +0300
description:
release-1.29.5 tag

diffstat:

 .hgtags |  1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diffs (8 lines):

diff --git a/.hgtags b/.hgtags
--- a/.hgtags
+++ b/.hgtags
@@ -490,3 +490,4 @@ 8ccd477736c998c0ea64c477b75c647cb28b356c
 56d817adaa1dd4f522114e921b1ff599c2ab4db2 release-1.29.2
 2175d3bea2a84f7265b90c6f9efea7fb9b41bdd7 release-1.29.3
 567870bfeb23f2e9c91e2a110d6d332c27c1ceb1 release-1.29.4
+4f4280557d20bc46ebbdc240ffd365f5ca6ce939 release-1.29.5

From mdounin at mdounin.ru  Tue Feb 10 16:47:09 2026
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 10 Feb 2026 19:47:09 +0300
Subject: [nginx-site] freenginx-1.29.5
Message-ID: <hg.52962a7d9eb4.1770742029.8954393999218941416@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/52962a7d9eb4
branches:  
changeset: 3128:52962a7d9eb4
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Feb 10 19:45:59 2026 +0300
description:
freenginx-1.29.5

diffstat:

 text/en/CHANGES    |  18 ++++++++++++++++++
 text/ru/CHANGES.ru |  18 ++++++++++++++++++
 xml/index.xml      |   7 +++++++
 xml/versions.xml   |   1 +
 4 files changed, 44 insertions(+), 0 deletions(-)

diffs (80 lines):

diff --git a/text/en/CHANGES b/text/en/CHANGES
--- a/text/en/CHANGES
+++ b/text/en/CHANGES
@@ -1,4 +1,22 @@
 
+Changes with freenginx 1.29.5                                    10 Feb 2026
+
+    *) Feature: optimized SSL_sendfile() usage on FreeBSD.
+       Thanks to Gleb Smirnoff.
+
+    *) Bugfix: upstream servers were not marked as failed after a response
+       with status code 500, 502, 503, 504, or 429 if the code was listed in
+       the "proxy_next_upstream" directive, but switching to the next server
+       was not possible.
+
+    *) Bugfix: the "stale-if-error" cache control extension was not applied
+       if a backend returned a response with status code 500, 502, 503, 504,
+       or 429 and the code was listed in the "proxy_next_upstream"
+       directive.
+
+    *) Bugfix: in handling of premature backend responses.
+
+
 Changes with freenginx 1.29.4                                    16 Dec 2025
 
     *) Feature: support for GeoIP2 databases in the MaxMind DB (MMDB) format
diff --git a/text/ru/CHANGES.ru b/text/ru/CHANGES.ru
--- a/text/ru/CHANGES.ru
+++ b/text/ru/CHANGES.ru
@@ -1,4 +1,22 @@
 
+????????? ? freenginx 1.29.5                                      10.02.2026
+
+    *) ??????????: ??????????? ????????????? SSL_sendfile() ?? FreeBSD.
+       ??????? ????? ????????.
+
+    *) ???????????: ??????? ?? ???????????? ????????????? ????? ?????????
+       ?????? ? ????? 500, 502, 503, 504 ??? 429, ???? ??????????????? ???
+       ??? ?????? ? ????????? proxy_next_upstream, ?? ???????? ??????? ??
+       ?????? ?????? ???? ??????????.
+
+    *) ???????????: ?????????? ?????????? ???????????? stale-if-error ??
+       ???????????, ???? ?????? ????????? ????? ? ????? 500, 502, 503, 504
+       ??? 429 ? ??????????????? ??? ??? ?????? ? ?????????
+       proxy_next_upstream.
+
+    *) ???????????: ? ????????? ??????????????? ??????? ????????.
+
+
 ????????? ? freenginx 1.29.4                                      16.12.2025
 
     *) ??????????: ????????? ??? ?????? GeoIP2 ? ??????? MaxMind DB (MMDB) ?
diff --git a/xml/index.xml b/xml/index.xml
--- a/xml/index.xml
+++ b/xml/index.xml
@@ -8,6 +8,13 @@
 
 <news name="freenginx news" link="/" lang="en">
 
+<event date="2026-02-10">
+<para>
+<link doc="en/download.xml">freenginx-1.29.5</link>
+mainline version has been released.
+</para>
+</event>
+
 <event date="2025-12-16">
 <para>
 <link doc="en/download.xml">freenginx-1.29.4</link>
diff --git a/xml/versions.xml b/xml/versions.xml
--- a/xml/versions.xml
+++ b/xml/versions.xml
@@ -9,6 +9,7 @@
 
 <download tag="mainline" changes="">
 
+<item ver="1.29.5" name="freenginx" />
 <item ver="1.29.4" name="freenginx" />
 <item ver="1.29.3" name="freenginx" />
 <item ver="1.29.2" name="freenginx" />

From devnexen at gmail.com  Thu Feb 19 09:32:55 2026
From: devnexen at gmail.com (David Carlier)
Date: Thu, 19 Feb 2026 09:32:55 +0000
Subject: [PATCH] Proxy: reset pending control frames on HTTP/2 upstream reinit.
Message-ID: <20260219093255.71292-1-devnexen@gmail.com>

Previously, ctx->out was not cleared in ngx_http_proxy_v2_reinit_request(),
which could cause stale HTTP/2 control frames (SETTINGS ACK, PING ACK,
WINDOW_UPDATE) queued for the old upstream connection to be sent to a new
upstream connection during a retry.
---
 src/http/modules/ngx_http_proxy_v2_module.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/http/modules/ngx_http_proxy_v2_module.c b/src/http/modules/ngx_http_proxy_v2_module.c
index 2c8a3d4d1..4c282a864 100644
--- a/src/http/modules/ngx_http_proxy_v2_module.c
+++ b/src/http/modules/ngx_http_proxy_v2_module.c
@@ -946,6 +946,7 @@ ngx_http_proxy_v2_reinit_request(ngx_http_request_t *r)
     ctx->connection = NULL;
     ctx->in = NULL;
     ctx->busy = NULL;
+    ctx->out = NULL;
 
     return NGX_OK;
 }
-- 
2.51.0


From mdounin at mdounin.ru  Fri Feb 20 01:42:23 2026
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 20 Feb 2026 04:42:23 +0300
Subject: [PATCH] Proxy: reset pending control frames on HTTP/2 upstream
 reinit.
In-Reply-To: <20260219093255.71292-1-devnexen@gmail.com>
References: <20260219093255.71292-1-devnexen@gmail.com>
Message-ID: <aZe7__8X6PAV7QuB@mdounin.ru>

Hello!

On Thu, Feb 19, 2026 at 09:32:55AM +0000, David Carlier wrote:

> Previously, ctx->out was not cleared in ngx_http_proxy_v2_reinit_request(),
> which could cause stale HTTP/2 control frames (SETTINGS ACK, PING ACK,
> WINDOW_UPDATE) queued for the old upstream connection to be sent to a new
> upstream connection during a retry.
> ---
>  src/http/modules/ngx_http_proxy_v2_module.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/http/modules/ngx_http_proxy_v2_module.c b/src/http/modules/ngx_http_proxy_v2_module.c
> index 2c8a3d4d1..4c282a864 100644
> --- a/src/http/modules/ngx_http_proxy_v2_module.c
> +++ b/src/http/modules/ngx_http_proxy_v2_module.c
> @@ -946,6 +946,7 @@ ngx_http_proxy_v2_reinit_request(ngx_http_request_t *r)
>      ctx->connection = NULL;
>      ctx->in = NULL;
>      ctx->busy = NULL;
> +    ctx->out = NULL;
>  
>      return NGX_OK;
>  }

The ngx_http_proxy_v2_module isn't something present in freenginx.  
You've probably mean to submit it to F5 NGINX instead.

On the other hand, there is the ngx_http_grpc_module, which 
apparently was used as a basis for ngx_http_proxy_v2_module, and 
it can suffer from similar issue.  If you are interested in 
contributing into freenginx, looking into the ngx_http_grpc_module 
might be the way to go.

-- 
Maxim Dounin
http://mdounin.ru/

From mdounin at mdounin.ru  Thu Feb 26 01:11:14 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Thu, 26 Feb 2026 04:11:14 +0300
Subject: [PATCH] Upstream: silenced "temporary disabled" warnings with
 variables
Message-ID: <90f2bd990f0cd4419fdf.1772068274@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1772067385 -10800
#      Thu Feb 26 03:56:25 2026 +0300
# Node ID 90f2bd990f0cd4419fdff3ac12f64ebcd80ad9e9
# Parent  c5a5aa2658d7bd6c0ec17600dc6be11b93e8c1f5
Upstream: silenced "temporary disabled" warnings with variables.

Previously, if a server within a runtime-created upstream, as used for
proxy_pass with variables, failed, the "upstream server temporarily disabled"
warning was logged.  For runtime-created upstreams the warning is useless
and confusing, since such upstreams are never used for other requests.

To disable the warning, max_fails is now set to 0 for runtime-created
upstreams.  Additionally, fail_timeout is also set to 0, for consistency.

diff --git a/src/http/ngx_http_upstream_round_robin.c b/src/http/ngx_http_upstream_round_robin.c
--- a/src/http/ngx_http_upstream_round_robin.c
+++ b/src/http/ngx_http_upstream_round_robin.c
@@ -356,8 +356,8 @@ ngx_http_upstream_create_round_robin_pee
         peer[0].effective_weight = 1;
         peer[0].current_weight = 0;
         peer[0].max_conns = 0;
-        peer[0].max_fails = 1;
-        peer[0].fail_timeout = 10;
+        peer[0].max_fails = 0;
+        peer[0].fail_timeout = 0;
         peers->peer = peer;
 
     } else {
@@ -390,8 +390,8 @@ ngx_http_upstream_create_round_robin_pee
             peer[i].effective_weight = 1;
             peer[i].current_weight = 0;
             peer[i].max_conns = 0;
-            peer[i].max_fails = 1;
-            peer[i].fail_timeout = 10;
+            peer[i].max_fails = 0;
+            peer[i].fail_timeout = 0;
             *peerp = &peer[i];
             peerp = &peer[i].next;
         }
diff --git a/src/stream/ngx_stream_upstream_round_robin.c b/src/stream/ngx_stream_upstream_round_robin.c
--- a/src/stream/ngx_stream_upstream_round_robin.c
+++ b/src/stream/ngx_stream_upstream_round_robin.c
@@ -366,8 +366,8 @@ ngx_stream_upstream_create_round_robin_p
         peer[0].effective_weight = 1;
         peer[0].current_weight = 0;
         peer[0].max_conns = 0;
-        peer[0].max_fails = 1;
-        peer[0].fail_timeout = 10;
+        peer[0].max_fails = 0;
+        peer[0].fail_timeout = 0;
         peers->peer = peer;
 
     } else {
@@ -400,8 +400,8 @@ ngx_stream_upstream_create_round_robin_p
             peer[i].effective_weight = 1;
             peer[i].current_weight = 0;
             peer[i].max_conns = 0;
-            peer[i].max_fails = 1;
-            peer[i].fail_timeout = 10;
+            peer[i].max_fails = 0;
+            peer[i].fail_timeout = 0;
             *peerp = &peer[i];
             peerp = &peer[i].next;
         }


From mdounin at mdounin.ru  Thu Feb 26 01:13:36 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Thu, 26 Feb 2026 04:13:36 +0300
Subject: [PATCH] gRPC: reinitialization of in, out, and busy chains
Message-ID: <125ca4a7d885b9c30f87.1772068416@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1772068294 -10800
#      Thu Feb 26 04:11:34 2026 +0300
# Node ID 125ca4a7d885b9c30f8745dccef669f29d91a68a
# Parent  90f2bd990f0cd4419fdff3ac12f64ebcd80ad9e9
gRPC: reinitialization of in, out, and busy chains.

If an error happens with data buffered in ctx->in (or control frames
queued in ctx->out), keeping these while switching to the next upstream
server will result in incorrect data sent to the new connection, likely
causing a failure.

Similarly, if there are buffers in ctx->busy, switching to the next
upstream server will reinitialize ngx_chain_writer() context, u->writer,
and these buffers will be forgotten.  Still, since they are in ctx->busy
and not marked as fully sent, ngx_chain_update_chains() won't look any
further, thus breaking buffers reuse and causing excessive memory usage
on long-running requests.

The fix is to clear ctx->in, ctx->out, and ctx->busy chains on request
reinitialization.

Prodded by David Carlier,
https://freenginx.org/pipermail/nginx-devel/2026-February/000934.html

diff --git a/src/http/modules/ngx_http_grpc_module.c b/src/http/modules/ngx_http_grpc_module.c
--- a/src/http/modules/ngx_http_grpc_module.c
+++ b/src/http/modules/ngx_http_grpc_module.c
@@ -1217,6 +1217,9 @@ ngx_http_grpc_reinit_request(ngx_http_re
     ctx->rst = 0;
     ctx->goaway = 0;
     ctx->connection = NULL;
+    ctx->in = NULL;
+    ctx->out = NULL;
+    ctx->busy = NULL;
     ctx->pings = 0;
     ctx->settings = 0;
     ctx->headers = 0;


From mdounin at mdounin.ru  Thu Feb 26 01:17:42 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Thu, 26 Feb 2026 04:17:42 +0300
Subject: [PATCH 1 of 2] Xslt: fixed vsnprintf() usage
Message-ID: <525677dd6b0a766fc617.1772068662@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1772068486 -10800
#      Thu Feb 26 04:14:46 2026 +0300
# Node ID 525677dd6b0a766fc61796ce4d74b5619132d33e
# Parent  125ca4a7d885b9c30f8745dccef669f29d91a68a
Xslt: fixed vsnprintf() usage.

Previously, vsnprintf(), as used to handle error messages from the
libxml2 library in ngx_http_xslt_sax_error(), was used incorrectly: the
code assumed that vsnprintf() returns the number of bytes actually
printed, and never fails.  But vsnprintf(), as originally introduced in
4.4BSD and later standardized in C99, returns the number of characters
that would have been written with a sufficiently large buffer, and "if
the return value is greater than or equal to the size argument, the
string was too short and some of the printed characters were discarded".
Additionally, vsnprintf() might theoretically result in a zero-length
error message, or might fail (for example, due to an incorrect format
specification in libxml2).  Most notably, this can result in
out-of-bounds reads and segmentation faults in the worker process on
very long error messages.

The fix is to check the value returned by vsnprintf() and properly
handle too long error messages, as well as zero-length error messages
and vsnprintf() failures.

diff --git a/src/http/modules/ngx_http_xslt_filter_module.c b/src/http/modules/ngx_http_xslt_filter_module.c
--- a/src/http/modules/ngx_http_xslt_filter_module.c
+++ b/src/http/modules/ngx_http_xslt_filter_module.c
@@ -540,23 +540,36 @@ ngx_http_xslt_sax_error(void *data, cons
 {
     xmlParserCtxtPtr ctxt = data;
 
-    size_t                       n;
+    int                          n;
     va_list                      args;
+    ngx_uint_t                   truncated;
     ngx_http_xslt_filter_ctx_t  *ctx;
     u_char                       buf[NGX_MAX_ERROR_STR];
 
     ctx = ctxt->sax->_private;
 
     buf[0] = '\0';
+    truncated = 0;
 
     va_start(args, msg);
-    n = (size_t) vsnprintf((char *) buf, NGX_MAX_ERROR_STR, msg, args);
+    n = vsnprintf((char *) buf, NGX_MAX_ERROR_STR, msg, args);
     va_end(args);
 
-    while (--n && (buf[n] == CR || buf[n] == LF)) { /* void */ }
+    if (n < 0) {
+        n = 0;
+        truncated = 1;
+    }
+
+    if (n >= NGX_MAX_ERROR_STR) {
+        n = NGX_MAX_ERROR_STR - 1;
+        truncated = 1;
+    }
+
+    while (n && (buf[n - 1] == CR || buf[n - 1] == LF)) { n--; }
 
     ngx_log_error(NGX_LOG_ERR, ctx->request->connection->log, 0,
-                  "libxml2 error: \"%*s\"", n + 1, buf);
+                  "libxml2 error: \"%*s%s\"",
+                  (size_t) n, buf, truncated ? "..." : "");
 }
 
 


From mdounin at mdounin.ru  Thu Feb 26 01:17:43 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Thu, 26 Feb 2026 04:17:43 +0300
Subject: [PATCH 2 of 2] Xslt: proper logging of long errors
In-Reply-To: <525677dd6b0a766fc617.1772068662@vm-bsd.mdounin.ru>
References: <525677dd6b0a766fc617.1772068662@vm-bsd.mdounin.ru>
Message-ID: <9f204b12e0b421f0255f.1772068663@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1772068488 -10800
#      Thu Feb 26 04:14:48 2026 +0300
# Node ID 9f204b12e0b421f0255f2e92e31d4b56a0657c2d
# Parent  525677dd6b0a766fc61796ce4d74b5619132d33e
Xslt: proper logging of long errors.

To ensure that long error messages from the libxml2 library can be
properly logged by ngx_http_xslt_sax_error(), the buffer size was
changed to NGX_MAX_CONF_ERRSTR.  It is smaller than NGX_MAX_ERROR_STR,
the size of the low-level buffer used during logging, and therefore
reserves some space for other information.  Similar approach is used
in ngx_conf_log_error(), where the macro comes from, as well as various
other places, such as ngx_ssl_error().

diff --git a/src/http/modules/ngx_http_xslt_filter_module.c b/src/http/modules/ngx_http_xslt_filter_module.c
--- a/src/http/modules/ngx_http_xslt_filter_module.c
+++ b/src/http/modules/ngx_http_xslt_filter_module.c
@@ -544,7 +544,7 @@ ngx_http_xslt_sax_error(void *data, cons
     va_list                      args;
     ngx_uint_t                   truncated;
     ngx_http_xslt_filter_ctx_t  *ctx;
-    u_char                       buf[NGX_MAX_ERROR_STR];
+    u_char                       buf[NGX_MAX_CONF_ERRSTR];
 
     ctx = ctxt->sax->_private;
 
@@ -552,7 +552,7 @@ ngx_http_xslt_sax_error(void *data, cons
     truncated = 0;
 
     va_start(args, msg);
-    n = vsnprintf((char *) buf, NGX_MAX_ERROR_STR, msg, args);
+    n = vsnprintf((char *) buf, NGX_MAX_CONF_ERRSTR, msg, args);
     va_end(args);
 
     if (n < 0) {
@@ -560,8 +560,8 @@ ngx_http_xslt_sax_error(void *data, cons
         truncated = 1;
     }
 
-    if (n >= NGX_MAX_ERROR_STR) {
-        n = NGX_MAX_ERROR_STR - 1;
+    if (n >= NGX_MAX_CONF_ERRSTR) {
+        n = NGX_MAX_CONF_ERRSTR - 1;
         truncated = 1;
     }
 


From mdounin at mdounin.ru  Thu Feb 26 03:18:44 2026
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Thu, 26 Feb 2026 06:18:44 +0300
Subject: [PATCH] SSL: added missing "goto failed" in ECH handling with
 BoringSSL
Message-ID: <e9ff0a43ca4d265a883b.1772075924@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1772075900 -10800
#      Thu Feb 26 06:18:20 2026 +0300
# Node ID e9ff0a43ca4d265a883b3df523c2a8db03c6e99e
# Parent  c5a5aa2658d7bd6c0ec17600dc6be11b93e8c1f5
SSL: added missing "goto failed" in ECH handling with BoringSSL.

The "goto failed" statement was missed in the EVP_HPKE_KEY_new() error
handling, as used during configuration of Encrypted Client Hello (ECH)
with BoringSSL, resulting in segmentation fault in EVP_HPKE_KEY_init()
if memory allocation in EVP_HPKE_KEY_new() failed.  Missed in
9422:deb1ec630f7c (1.29.2).

Reported by Yu Zhu,
https://github.com/freenginx/nginx/issues/16

diff --git a/src/event/ngx_event_openssl.c b/src/event/ngx_event_openssl.c
--- a/src/event/ngx_event_openssl.c
+++ b/src/event/ngx_event_openssl.c
@@ -2023,6 +2023,7 @@ failed:
         if (hpkey == NULL) {
             ngx_ssl_error(NGX_LOG_EMERG, ssl->log, 0,
                           "EVP_HPKE_KEY_new() failed");
+            goto failed;
         }
 
         if (EVP_HPKE_KEY_init(hpkey, EVP_hpke_x25519_hkdf_sha256(),