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/