From mdounin at mdounin.ru  Mon Sep  2 06:10:06 2024
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Mon, 02 Sep 2024 09:10:06 +0300
Subject: [PATCH] Reworked auth_basic_user_file documentation
Message-ID: <aea3e104f11deba904f8.1725257406@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1725070765 -10800
#      Sat Aug 31 05:19:25 2024 +0300
# Node ID aea3e104f11deba904f88166ddd1befe79621ec1
# Parent  f7e9bd7de0f9a4fbb476b4a6217de3bb55cdaa7b
Reworked auth_basic_user_file documentation.

Some extra details about crypt(3) are provided, emphasizing modular
crypt() usage and commonly available password hashing methods.  Also,
added some examples on how to use "openssl passwd" to generate password
hashes, made it clear that {SSHA} passwords are not secure now, and
added a note about passwords being validated on each request.

diff --git a/xml/en/docs/http/ngx_http_auth_basic_module.xml b/xml/en/docs/http/ngx_http_auth_basic_module.xml
--- a/xml/en/docs/http/ngx_http_auth_basic_module.xml
+++ b/xml/en/docs/http/ngx_http_auth_basic_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_auth_basic_module"
         link="/en/docs/http/ngx_http_auth_basic_module.html"
         lang="en"
-        rev="11">
+        rev="12">
 
 <section id="summary">
 
@@ -89,18 +89,37 @@ The <value>file</value> name can contain
 </para>
 
 <para>
-The following password types are supported:
+Passwords are expected to be encrypted by the
+<link url="https://en.wikipedia.org/wiki/Crypt_(C)">crypt() function</link>.
+All password hashing methods as supported by the OS can be used.
+In particular, the following <c-func>crypt</c-func> hashing methods are
+commonly available:
+
 <list type="bullet">
 
 <listitem>
-encrypted with the <c-func>crypt</c-func> function; can be generated using
-the ?<command>htpasswd</command>? utility from the Apache HTTP Server
-distribution or the ?<command>openssl passwd</command>? command;
+MD5-based <c-func>crypt</c-func> method, <literal>$1$</literal>;
+</listitem>
+
+<listitem>
+SHA256-based <c-func>crypt</c-func> method, <literal>$5$</literal>;
 </listitem>
 
 <listitem>
-hashed with the Apache variant of the MD5-based password algorithm (apr1);
-can be generated with the same tools;
+SHA512-based <c-func>crypt</c-func> method, <literal>$6$</literal>.
+</listitem>
+
+</list>
+</para>
+
+<para>
+Additionally, the following cross-platform password types are supported:
+
+<list type="bullet">
+
+<listitem>
+hashed with the Apache variant of the MD5-based <c-func>crypt</c-func>
+method (<literal>$apr1$</literal>);
 </listitem>
 
 <listitem>
@@ -108,23 +127,36 @@ specified by the
 ?<literal>{</literal><value>scheme</value><literal>}</literal><value>data</value>?
 syntax (1.0.3+) as described in
 <link url="https://datatracker.ietf.org/doc/html/rfc2307#section-5.3">RFC 2307</link>;
-currently implemented schemes include <literal>PLAIN</literal> (an example one,
-should not be used), <literal>SHA</literal> (1.3.13) (plain SHA-1
-hashing, should not be used) and <literal>SSHA</literal> (salted SHA-1 hashing,
-used by some software packages, notably OpenLDAP and Dovecot).
-<note>
-Support for <literal>SHA</literal> scheme was added only to aid
-in migration from other web servers.
-It should not be used for new passwords, since unsalted SHA-1 hashing
-that it employs is vulnerable to
-<link url="http://en.wikipedia.org/wiki/Rainbow_attack">rainbow table</link>
-attacks.
-</note>
+supported schemes are
+<literal>PLAIN</literal> (an example one, should not be used),
+<literal>SHA</literal> (1.3.13) (plain SHA-1 hashing,
+insecure and should not be used),
+and <literal>SSHA</literal> (salted SHA-1 hashing,
+also insecure by today's standards).
 </listitem>
 
 </list>
 </para>
 
+<para>
+Password hashes for common hashing methods can be generated using
+the ?<command>openssl passwd</command>? command, for example:
+
+<example>
+$ openssl passwd -apr1 secret
+$apr1$x/muFo1c$zwUN24M2TEq.6wg0AZacn0
+</example>
+<example>
+$ openssl passwd -6 secret
+$6$FjZ1ss8ytcGmrGFY$1fopTJLuLUGCRlv2YcRPIsZk9uaD9NBOGcKsUay/BLV3RR1ol0ONS08oPTVqA4XBkZ44M7OL4K6NjP9xPKShP0
+</example>
+</para>
+
+<para>
+Note that HTTP Basic Authentication implies password validation on each
+request, and password hashing method should be choosen with this in mind.
+</para>
+
 </directive>
 
 </section>
diff --git a/xml/ru/docs/http/ngx_http_auth_basic_module.xml b/xml/ru/docs/http/ngx_http_auth_basic_module.xml
--- a/xml/ru/docs/http/ngx_http_auth_basic_module.xml
+++ b/xml/ru/docs/http/ngx_http_auth_basic_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_auth_basic_module"
         link="/ru/docs/http/ngx_http_auth_basic_module.html"
         lang="ru"
-        rev="11">
+        rev="12">
 
 <section id="summary">
 
@@ -89,18 +89,35 @@ location / {
 </para>
 
 <para>
-?????????????? ????????? ???? ???????:
+?????? ?????? ???? ???????????
+<link url="https://ru.wikipedia.org/wiki/Crypt_(C)">???????? crypt()</link>.
+???????? ??? ?????? ??????????? ???????, ?????????????? ???????????? ????????.
+? ?????????, ?????????????? ????????? ?????? ???????????:
+
 <list type="bullet">
 
 <listitem>
-????????????? ???????? <c-func>crypt</c-func>; ????? ???? ???????
-? ??????? ??????? ?<command>htpasswd</command>? ?? ???????????? HTTP-???????
-Apache ??? ??????? ?<command>openssl passwd</command>?;
+?????????? ?? MD5 ?????, <literal>$1$</literal>;
+</listitem>
+
+<listitem>
+?????????? ?? SHA256 ?????, <literal>$5$</literal>;
 </listitem>
 
 <listitem>
-???????????? ? ??????? ?????????, ??????????? ?? MD5, ?? ?????? Apache (apr1);
-????? ???? ??????? ???? ?? ?????????????;
+?????????? ?? SHA512 ?????, <literal>$6$</literal>.
+</listitem>
+
+</list>
+</para>
+
+<para>
+????? ????, ?????????????? ????????? ?????-????????????? ???? ???????:
+<list type="bullet">
+
+<listitem>
+???????????? ? ??????? ??????????? ?? MD5 ?????? ?? ?????? Apache
+(<literal>$apr1$</literal>);
 </listitem>
 
 <listitem>
@@ -111,20 +128,31 @@ Apache ??? ??????? ?<command>openssl passwd</command>?;
 ? ????????? ?????? ??????????? ????? <literal>PLAIN</literal> (? ????????
 ???????, ?? ??????? ?????????), <literal>SHA</literal> (1.3.13) (??????? SHA-1
 ???????????, ?? ??????? ?????????) ? <literal>SSHA</literal> (SHA-1 ???????????
-? ?????, ???????????? ? ????????? ??????????, ? ????????? OpenLDAP
-? Dovecot).
-<note>
-????????? ????? <literal>SHA</literal> ???? ????????? ???? ??? ??????????
-???????? ???????? ?????? ??????? ? ?????? ???-????????.
-?? ?? ??????? ????????? ??? ????? ???????, ?.?. ???????????? ??? ????
-SHA-1 ??????????? ??? ???? ??????? ? ?????? ??? ??????
-<link url="http://en.wikipedia.org/wiki/Rainbow_attack">???????? ??????</link>.
-</note>
+? ?????, ????? ??????????? ?? ??????????? ??????????).
 </listitem>
 
 </list>
 </para>
 
+<para>
+???? ??????? ??? ????????????????? ??????? ??????????? ????? ???? ?????????????
+? ??????? ??????? ?<command>openssl passwd</command>?, ????????:
+
+<example>
+$ openssl passwd -apr1 secret
+$apr1$x/muFo1c$zwUN24M2TEq.6wg0AZacn0
+</example>
+<example>
+$ openssl passwd -6 secret
+$6$FjZ1ss8ytcGmrGFY$1fopTJLuLUGCRlv2YcRPIsZk9uaD9NBOGcKsUay/BLV3RR1ol0ONS08oPTVqA4XBkZ44M7OL4K6NjP9xPKShP0
+</example>
+</para>
+
+<para>
+??? ?????? ?????? ??????????? ??????? ??????? ?????????, ???
+HTTP Basic Authentication ????????????? ???????? ?????? ??? ?????? ???????.
+</para>
+
 </directive>
 
 </section>

From mdounin at mdounin.ru  Mon Sep  2 06:36:30 2024
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Mon, 02 Sep 2024 09:36:30 +0300
Subject: [PATCH] Documented charset_types changes
Message-ID: <ddf686b02cebbb264de6.1725258990@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1725258906 -10800
#      Mon Sep 02 09:35:06 2024 +0300
# Node ID ddf686b02cebbb264de66e59be32c8a7b228ea21
# Parent  aea3e104f11deba904f88166ddd1befe79621ec1
Documented charset_types changes.

diff --git a/xml/en/docs/http/ngx_http_charset_module.xml b/xml/en/docs/http/ngx_http_charset_module.xml
--- a/xml/en/docs/http/ngx_http_charset_module.xml
+++ b/xml/en/docs/http/ngx_http_charset_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_charset_module"
         link="/en/docs/http/ngx_http_charset_module.html"
         lang="en"
-        rev="5">
+        rev="6">
 
 <section id="summary">
 
@@ -165,8 +165,8 @@ are provided in the distribution files <
 
 <directive name="charset_types">
 <syntax><value>mime-type</value> ...</syntax>
-<default>text/html text/xml text/plain text/vnd.wap.wml
-application/javascript application/rss+xml</default>
+<default>text/html text/xml text/javascript text/plain text/markdown
+text/vnd.wap.wml application/javascript application/rss+xml</default>
 <context>http</context>
 <context>server</context>
 <context>location</context>
@@ -180,9 +180,13 @@ The special value ?<literal>*</literal>? matches any MIME type (0.8.29).
 
 <para>
 <note>
-Until version 1.5.4, ?<literal>application/x-javascript</literal>? was used
+Prior to version 1.5.4, ?<literal>application/x-javascript</literal>? was used
 as the default MIME type instead of ?<literal>application/javascript</literal>?.
 </note>
+<note>
+Prior to version 1.27.4, the default value did not include
+?<literal>text/javascript</literal>? and ?<literal>text/markdown</literal>?.
+</note>
 </para>
 
 </directive>
diff --git a/xml/ru/docs/http/ngx_http_charset_module.xml b/xml/ru/docs/http/ngx_http_charset_module.xml
--- a/xml/ru/docs/http/ngx_http_charset_module.xml
+++ b/xml/ru/docs/http/ngx_http_charset_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_charset_module"
         link="/ru/docs/http/ngx_http_charset_module.html"
         lang="ru"
-        rev="5">
+        rev="6">
 
 <section id="summary">
 
@@ -164,8 +164,8 @@ charset_map koi8-r utf-8 {
 
 <directive name="charset_types">
 <syntax><value>mime-???</value> ...</syntax>
-<default>text/html text/xml text/plain text/vnd.wap.wml
-application/javascript application/rss+xml</default>
+<default>text/html text/xml text/javascript text/plain text/markdown
+text/vnd.wap.wml application/javascript application/rss+xml</default>
 <context>http</context>
 <context>server</context>
 <context>location</context>
@@ -184,6 +184,10 @@ application/javascript application/rss+x
 ?<literal>application/javascript</literal>? ?????????????
 ?<literal>application/x-javascript</literal>?.
 </note>
+<note>
+?? ?????? 1.27.4 ???????? ?? ????????? ?? ????????
+?<literal>text/javascript</literal>? ? ?<literal>text/markdown</literal>?.
+</note>
 </para>
 
 </directive>

From mdounin at mdounin.ru  Mon Sep  2 07:11:10 2024
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Mon, 02 Sep 2024 10:11:10 +0300
Subject: [PATCH 1 of 2] Documented the $ssl_client_fingerprint_sha256 variable
Message-ID: <807f064844a578b4eb71.1725261070@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1725259793 -10800
#      Mon Sep 02 09:49:53 2024 +0300
# Node ID 807f064844a578b4eb717ecb254ff4b248a9a08e
# Parent  ddf686b02cebbb264de66e59be32c8a7b228ea21
Documented the $ssl_client_fingerprint_sha256 variable.

diff --git a/xml/en/docs/http/ngx_http_ssl_module.xml b/xml/en/docs/http/ngx_http_ssl_module.xml
--- a/xml/en/docs/http/ngx_http_ssl_module.xml
+++ b/xml/en/docs/http/ngx_http_ssl_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_ssl_module"
         link="/en/docs/http/ngx_http_ssl_module.html"
         lang="en"
-        rev="63">
+        rev="64">
 
 <section id="summary">
 
@@ -1059,6 +1059,12 @@ returns the SHA1 fingerprint of the clie
 for an established SSL connection (1.7.1);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+returns the SHA256 fingerprint of the client certificate
+for an established SSL connection (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 returns the ?issuer?DN? string of the client certificate
diff --git a/xml/en/docs/stream/ngx_stream_ssl_module.xml b/xml/en/docs/stream/ngx_stream_ssl_module.xml
--- a/xml/en/docs/stream/ngx_stream_ssl_module.xml
+++ b/xml/en/docs/stream/ngx_stream_ssl_module.xml
@@ -9,7 +9,7 @@
 <module name="Module ngx_stream_ssl_module"
         link="/en/docs/stream/ngx_stream_ssl_module.html"
         lang="en"
-        rev="32">
+        rev="33">
 
 <section id="summary">
 
@@ -716,6 +716,12 @@ returns the SHA1 fingerprint of the clie
 for an established SSL connection (1.11.8);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+returns the SHA256 fingerprint of the client certificate
+for an established SSL connection (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 returns the ?issuer?DN? string of the client certificate
diff --git a/xml/ru/docs/http/ngx_http_ssl_module.xml b/xml/ru/docs/http/ngx_http_ssl_module.xml
--- a/xml/ru/docs/http/ngx_http_ssl_module.xml
+++ b/xml/ru/docs/http/ngx_http_ssl_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_ssl_module"
         link="/ru/docs/http/ngx_http_ssl_module.html"
         lang="ru"
-        rev="63">
+        rev="64">
 
 <section id="summary">
 
@@ -1066,6 +1066,12 @@ AES128-SHA:AES256-SHA:0x00ff
 ??? ?????????????? SSL-?????????? (1.7.1);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+?????????? SHA256-????????? ??????????? ???????????
+??? ?????????????? SSL-?????????? (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 ?????????? ?????? ?issuer?DN? ??????????? ???????????
diff --git a/xml/ru/docs/stream/ngx_stream_ssl_module.xml b/xml/ru/docs/stream/ngx_stream_ssl_module.xml
--- a/xml/ru/docs/stream/ngx_stream_ssl_module.xml
+++ b/xml/ru/docs/stream/ngx_stream_ssl_module.xml
@@ -9,7 +9,7 @@
 <module name="?????? ngx_stream_ssl_module"
         link="/ru/docs/stream/ngx_stream_ssl_module.html"
         lang="ru"
-        rev="32">
+        rev="33">
 
 <section id="summary">
 
@@ -721,6 +721,12 @@ AES128-SHA:AES256-SHA:0x00ff
 ??? ?????????????? SSL-?????????? (1.11.8);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+?????????? SHA256-????????? ??????????? ???????????
+??? ?????????????? SSL-?????????? (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 ?????????? ?????? ?issuer?DN? ??????????? ???????????

From mdounin at mdounin.ru  Mon Sep  2 07:11:11 2024
From: mdounin at mdounin.ru (=?utf-8?q?Maxim_Dounin?=)
Date: Mon, 02 Sep 2024 10:11:11 +0300
Subject: [PATCH 2 of 2] Documented Auth-SSL-Fingerprint-SHA256 in mail proxy
In-Reply-To: <807f064844a578b4eb71.1725261070@vm-bsd.mdounin.ru>
References: <807f064844a578b4eb71.1725261070@vm-bsd.mdounin.ru>
Message-ID: <400dfceb9affedd1167c.1725261071@vm-bsd.mdounin.ru>

# HG changeset patch
# User Maxim Dounin <mdounin at mdounin.ru>
# Date 1725260939 -10800
#      Mon Sep 02 10:08:59 2024 +0300
# Node ID 400dfceb9affedd1167cb28a416a2b3d10d8368e
# Parent  807f064844a578b4eb717ecb254ff4b248a9a08e
Documented Auth-SSL-Fingerprint-SHA256 in mail proxy.

diff --git a/xml/en/docs/mail/ngx_mail_auth_http_module.xml b/xml/en/docs/mail/ngx_mail_auth_http_module.xml
--- a/xml/en/docs/mail/ngx_mail_auth_http_module.xml
+++ b/xml/en/docs/mail/ngx_mail_auth_http_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_mail_auth_http_module"
         link="/en/docs/mail/ngx_mail_auth_http_module.html"
         lang="en"
-        rev="12">
+        rev="13">
 
 <section id="directives" name="Directives">
 
@@ -229,7 +229,8 @@ did not contain the <value>reason</value
 When the client certificate was present,
 its details are passed in the following request headers:
 <header>Auth-SSL-Subject</header>, <header>Auth-SSL-Issuer</header>,
-<header>Auth-SSL-Serial</header>, and <header>Auth-SSL-Fingerprint</header>.
+<header>Auth-SSL-Serial</header>, <header>Auth-SSL-Fingerprint</header>,
+and <header>Auth-SSL-Fingerprint-SHA256</header> (1.27.4).
 If <link id="auth_http_pass_client_cert"/> is enabled,
 the certificate itself is passed in the
 <header>Auth-SSL-Cert</header> header.
@@ -254,6 +255,7 @@ Auth-SSL-Subject: /CN=example.com
 Auth-SSL-Issuer: /CN=example.com
 Auth-SSL-Serial: C07AD56B846B5BFF
 Auth-SSL-Fingerprint: 29d6a80a123d13355ed16b4b04605e29cb55a5ad
+Auth-SSL-Fingerprint-SHA256: 8b489b945bd45dd8e229e40f4e9bbc2ee13c70dd82831e197e4084bccc0476d2
 </example>
 </para>
 
diff --git a/xml/ru/docs/mail/ngx_mail_auth_http_module.xml b/xml/ru/docs/mail/ngx_mail_auth_http_module.xml
--- a/xml/ru/docs/mail/ngx_mail_auth_http_module.xml
+++ b/xml/ru/docs/mail/ngx_mail_auth_http_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_mail_auth_http_module"
         link="/ru/docs/mail/ngx_mail_auth_http_module.html"
         lang="ru"
-        rev="12">
+        rev="13">
 
 <section id="directives" name="?????????">
 
@@ -227,7 +227,8 @@ url="https://developers.google.com/gmail
 ???? ?????????? ?????????? ??? ????????????,
 ?????????? ? ??? ?????????? ? ????????? ?????????? ???????:
 <header>Auth-SSL-Subject</header>, <header>Auth-SSL-Issuer</header>,
-<header>Auth-SSL-Serial</header> ? <header>Auth-SSL-Fingerprint</header>.
+<header>Auth-SSL-Serial</header>, <header>Auth-SSL-Fingerprint</header>
+? <header>Auth-SSL-Fingerprint-SHA256</header> (1.27.4).
 ???? ????????? <link id="auth_http_pass_client_cert"/> ????????,
 ??? ?????????? ?????????? ? ?????????
 <header>Auth-SSL-Cert</header>.
@@ -252,6 +253,7 @@ Auth-SSL-Subject: /CN=example.com
 Auth-SSL-Issuer: /CN=example.com
 Auth-SSL-Serial: C07AD56B846B5BFF
 Auth-SSL-Fingerprint: 29d6a80a123d13355ed16b4b04605e29cb55a5ad
+Auth-SSL-Fingerprint-SHA256: 8b489b945bd45dd8e229e40f4e9bbc2ee13c70dd82831e197e4084bccc0476d2
 </example>
 </para>
 

From mdounin at mdounin.ru  Tue Sep  3 05:19:57 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Tue, 3 Sep 2024 08:19:57 +0300
Subject: freenginx-1.27.4 changes draft
Message-ID: <ZtacfYALLLYwVOEy@mdounin.ru>

Hello!

Below are CHANGES draft for the upcoming freenginx release, 
1.27.4.  Review and comments are welcome.


Changes with freenginx 1.27.4                                    03 Sep 2024

    *) Feature: the $ssl_client_fingerprint_sha256 variable.

    *) Feature: the "Auth-SSL-Fingerprint-SHA256 header line is now passed
       to the mail proxy authentication server.

    *) Change: MIME type for the "js" extension has been changed to
       "text/javascript", the "mjs" extension now uses the "text/javascript"
       MIME type, and the "md" and "markdown" extensions now use the
       "text/markdown" MIME type; the default value of the "charset_types"
       directive now includes "text/javascript" and "text/markdown".

    *) Bugfix: a segmentation fault might occur in a worker process if the
       ngx_http_mp4_module was used; the bug had appeared in 1.5.13.

    *) Bugfix: a segmentation fault might occur in a worker process when
       handling requests with the "Expect: 100-continue" request header
       line; the bug had appeared in 1.27.0.


????????? ? freenginx 1.27.4                                      03.09.2024

    *) ??????????: ?????????? $ssl_client_fingerprint_sha256.

    *) ??????????: ?????? ??????? ?????????????? ????????? ??????-???????
       ?????????? ?????? ????????? "Auth-SSL-Fingerprint-SHA256".

    *) ?????????: MIME-??? ??? ?????????? js ??????? ?? "text/javascript",
       ??? ?????????? mjs ?????? ???????????? ??? "text/javascript", ???
       ?????????? md ? markdown ?????? ???????????? ??? "text/markdown";
       ???????? ?? ????????? ????????? charset_types ?????? ????????
       "text/javascript" ? "text/markdown".

    *) ???????????: ? ??????? ???????? ??? ????????? segmentation fault,
       ???? ????????????? ?????? ngx_http_mp4_module; ?????? ????????? ?
       1.5.13.

    *) ???????????: ??? ????????? ???????? ?? ??????? "Expect: 100-continue"
       ? ????????? ??????? ? ??????? ???????? ??? ????????? segmentation
       fault; ?????? ????????? ? 1.27.0.


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

From mdounin at mdounin.ru  Tue Sep  3 10:18:02 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:02 +0300
Subject: [nginx] freenginx-1.27.4-RELEASE
Message-ID: <hg.3e58802df709.1725358682.441229195082064774@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/3e58802df709
branches:  
changeset: 9330:3e58802df709
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Sep 03 13:11:24 2024 +0300
description:
freenginx-1.27.4-RELEASE

diffstat:

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

diffs (78 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,74 @@
 <section title="freenginx">
 
 
+<changes ver="1.27.4" date="2024-09-03">
+
+<change type="feature">
+<para lang="ru">
+?????????? $ssl_client_fingerprint_sha256.
+</para>
+<para lang="en">
+the $ssl_client_fingerprint_sha256 variable.
+</para>
+</change>
+
+<change type="feature">
+<para lang="ru">
+?????? ??????? ?????????????? ????????? ??????-???????
+?????????? ?????? ????????? "Auth-SSL-Fingerprint-SHA256".
+</para>
+<para lang="en">
+the "Auth-SSL-Fingerprint-SHA256 header line
+is now passed to the mail proxy authentication server.
+</para>
+</change>
+
+<change type="change">
+<para lang="ru">
+MIME-??? ??? ?????????? js ??????? ?? "text/javascript",
+??? ?????????? mjs ?????? ???????????? ??? "text/javascript",
+??? ?????????? md ? markdown ?????? ???????????? ??? "text/markdown";
+???????? ?? ????????? ????????? charset_types ?????? ????????
+"text/javascript" ? "text/markdown".
+</para>
+<para lang="en">
+MIME type for the "js" extension has been changed to "text/javascript",
+the "mjs" extension now uses the "text/javascript" MIME type,
+and the "md" and "markdown" extensions now use the "text/markdown" MIME type;
+the default value of the "charset_types" directive now includes
+"text/javascript" and "text/markdown".
+</para>
+</change>
+
+<change type="bugfix">
+<para lang="ru">
+? ??????? ???????? ??? ????????? segmentation fault,
+???? ????????????? ?????? ngx_http_mp4_module;
+?????? ????????? ? 1.5.13.
+</para>
+<para lang="en">
+a segmentation fault might occur in a worker process
+if the ngx_http_mp4_module was used;
+the bug had appeared in 1.5.13.
+</para>
+</change>
+
+<change type="bugfix">
+<para lang="ru">
+??? ????????? ???????? ?? ??????? "Expect: 100-continue" ? ????????? ???????
+? ??????? ???????? ??? ????????? segmentation fault;
+?????? ????????? ? 1.27.0.
+</para>
+<para lang="en">
+a segmentation fault might occur in a worker process
+when handling requests with the "Expect: 100-continue" request header line;
+the bug had appeared in 1.27.0.
+</para>
+</change>
+
+</changes>
+
+
 <changes ver="1.27.3" date="2024-08-13">
 
 <change type="change">

From mdounin at mdounin.ru  Tue Sep  3 10:18:02 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:02 +0300
Subject: [nginx] release-1.27.4 tag
Message-ID: <hg.dbf76fdd109f.1725358682.441229195082064774@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx/rev/dbf76fdd109f
branches:  
changeset: 9331:dbf76fdd109f
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Sep 03 13:11:25 2024 +0300
description:
release-1.27.4 tag

diffstat:

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

diffs (8 lines):

diff --git a/.hgtags b/.hgtags
--- a/.hgtags
+++ b/.hgtags
@@ -482,3 +482,4 @@ 8c4e2b7de093d357b2f462399d6d395b899ffe76
 ee3eb2b9705f0c913a1bf4b9fe74def31411e8bf release-1.27.1
 91d77cc29d3336b1df25fe42d6c5ad4ca24b72b9 release-1.27.2
 665f7a7675cf4620c5d05cbcabdf72e6afe18b80 release-1.27.3
+3e58802df709d487e366809eef77f6424433d187 release-1.27.4

From mdounin at mdounin.ru  Tue Sep  3 10:18:46 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:46 +0300
Subject: [nginx-site] Reworked auth_basic_user_file documentation.
Message-ID: <hg.aea3e104f11d.1725358726.6391938264800526509@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/aea3e104f11d
branches:  
changeset: 3095:aea3e104f11d
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Sat Aug 31 05:19:25 2024 +0300
description:
Reworked auth_basic_user_file documentation.

Some extra details about crypt(3) are provided, emphasizing modular
crypt() usage and commonly available password hashing methods.  Also,
added some examples on how to use "openssl passwd" to generate password
hashes, made it clear that {SSHA} passwords are not secure now, and
added a note about passwords being validated on each request.

diffstat:

 xml/en/docs/http/ngx_http_auth_basic_module.xml |  70 ++++++++++++++++++------
 xml/ru/docs/http/ngx_http_auth_basic_module.xml |  60 +++++++++++++++-----
 2 files changed, 95 insertions(+), 35 deletions(-)

diffs (200 lines):

diff --git a/xml/en/docs/http/ngx_http_auth_basic_module.xml b/xml/en/docs/http/ngx_http_auth_basic_module.xml
--- a/xml/en/docs/http/ngx_http_auth_basic_module.xml
+++ b/xml/en/docs/http/ngx_http_auth_basic_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_auth_basic_module"
         link="/en/docs/http/ngx_http_auth_basic_module.html"
         lang="en"
-        rev="11">
+        rev="12">
 
 <section id="summary">
 
@@ -89,18 +89,37 @@ The <value>file</value> name can contain
 </para>
 
 <para>
-The following password types are supported:
+Passwords are expected to be encrypted by the
+<link url="https://en.wikipedia.org/wiki/Crypt_(C)">crypt() function</link>.
+All password hashing methods as supported by the OS can be used.
+In particular, the following <c-func>crypt</c-func> hashing methods are
+commonly available:
+
 <list type="bullet">
 
 <listitem>
-encrypted with the <c-func>crypt</c-func> function; can be generated using
-the ?<command>htpasswd</command>? utility from the Apache HTTP Server
-distribution or the ?<command>openssl passwd</command>? command;
+MD5-based <c-func>crypt</c-func> method, <literal>$1$</literal>;
+</listitem>
+
+<listitem>
+SHA256-based <c-func>crypt</c-func> method, <literal>$5$</literal>;
 </listitem>
 
 <listitem>
-hashed with the Apache variant of the MD5-based password algorithm (apr1);
-can be generated with the same tools;
+SHA512-based <c-func>crypt</c-func> method, <literal>$6$</literal>.
+</listitem>
+
+</list>
+</para>
+
+<para>
+Additionally, the following cross-platform password types are supported:
+
+<list type="bullet">
+
+<listitem>
+hashed with the Apache variant of the MD5-based <c-func>crypt</c-func>
+method (<literal>$apr1$</literal>);
 </listitem>
 
 <listitem>
@@ -108,23 +127,36 @@ specified by the
 ?<literal>{</literal><value>scheme</value><literal>}</literal><value>data</value>?
 syntax (1.0.3+) as described in
 <link url="https://datatracker.ietf.org/doc/html/rfc2307#section-5.3">RFC 2307</link>;
-currently implemented schemes include <literal>PLAIN</literal> (an example one,
-should not be used), <literal>SHA</literal> (1.3.13) (plain SHA-1
-hashing, should not be used) and <literal>SSHA</literal> (salted SHA-1 hashing,
-used by some software packages, notably OpenLDAP and Dovecot).
-<note>
-Support for <literal>SHA</literal> scheme was added only to aid
-in migration from other web servers.
-It should not be used for new passwords, since unsalted SHA-1 hashing
-that it employs is vulnerable to
-<link url="http://en.wikipedia.org/wiki/Rainbow_attack">rainbow table</link>
-attacks.
-</note>
+supported schemes are
+<literal>PLAIN</literal> (an example one, should not be used),
+<literal>SHA</literal> (1.3.13) (plain SHA-1 hashing,
+insecure and should not be used),
+and <literal>SSHA</literal> (salted SHA-1 hashing,
+also insecure by today's standards).
 </listitem>
 
 </list>
 </para>
 
+<para>
+Password hashes for common hashing methods can be generated using
+the ?<command>openssl passwd</command>? command, for example:
+
+<example>
+$ openssl passwd -apr1 secret
+$apr1$x/muFo1c$zwUN24M2TEq.6wg0AZacn0
+</example>
+<example>
+$ openssl passwd -6 secret
+$6$FjZ1ss8ytcGmrGFY$1fopTJLuLUGCRlv2YcRPIsZk9uaD9NBOGcKsUay/BLV3RR1ol0ONS08oPTVqA4XBkZ44M7OL4K6NjP9xPKShP0
+</example>
+</para>
+
+<para>
+Note that HTTP Basic Authentication implies password validation on each
+request, and password hashing method should be choosen with this in mind.
+</para>
+
 </directive>
 
 </section>
diff --git a/xml/ru/docs/http/ngx_http_auth_basic_module.xml b/xml/ru/docs/http/ngx_http_auth_basic_module.xml
--- a/xml/ru/docs/http/ngx_http_auth_basic_module.xml
+++ b/xml/ru/docs/http/ngx_http_auth_basic_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_auth_basic_module"
         link="/ru/docs/http/ngx_http_auth_basic_module.html"
         lang="ru"
-        rev="11">
+        rev="12">
 
 <section id="summary">
 
@@ -89,18 +89,35 @@ location / {
 </para>
 
 <para>
-?????????????? ????????? ???? ???????:
+?????? ?????? ???? ???????????
+<link url="https://ru.wikipedia.org/wiki/Crypt_(C)">???????? crypt()</link>.
+???????? ??? ?????? ??????????? ???????, ?????????????? ???????????? ????????.
+? ?????????, ?????????????? ????????? ?????? ???????????:
+
 <list type="bullet">
 
 <listitem>
-????????????? ???????? <c-func>crypt</c-func>; ????? ???? ???????
-? ??????? ??????? ?<command>htpasswd</command>? ?? ???????????? HTTP-???????
-Apache ??? ??????? ?<command>openssl passwd</command>?;
+?????????? ?? MD5 ?????, <literal>$1$</literal>;
+</listitem>
+
+<listitem>
+?????????? ?? SHA256 ?????, <literal>$5$</literal>;
 </listitem>
 
 <listitem>
-???????????? ? ??????? ?????????, ??????????? ?? MD5, ?? ?????? Apache (apr1);
-????? ???? ??????? ???? ?? ?????????????;
+?????????? ?? SHA512 ?????, <literal>$6$</literal>.
+</listitem>
+
+</list>
+</para>
+
+<para>
+????? ????, ?????????????? ????????? ?????-????????????? ???? ???????:
+<list type="bullet">
+
+<listitem>
+???????????? ? ??????? ??????????? ?? MD5 ?????? ?? ?????? Apache
+(<literal>$apr1$</literal>);
 </listitem>
 
 <listitem>
@@ -111,20 +128,31 @@ Apache ??? ??????? ?<command>openssl passwd</command>?;
 ? ????????? ?????? ??????????? ????? <literal>PLAIN</literal> (? ????????
 ???????, ?? ??????? ?????????), <literal>SHA</literal> (1.3.13) (??????? SHA-1
 ???????????, ?? ??????? ?????????) ? <literal>SSHA</literal> (SHA-1 ???????????
-? ?????, ???????????? ? ????????? ??????????, ? ????????? OpenLDAP
-? Dovecot).
-<note>
-????????? ????? <literal>SHA</literal> ???? ????????? ???? ??? ??????????
-???????? ???????? ?????? ??????? ? ?????? ???-????????.
-?? ?? ??????? ????????? ??? ????? ???????, ?.?. ???????????? ??? ????
-SHA-1 ??????????? ??? ???? ??????? ? ?????? ??? ??????
-<link url="http://en.wikipedia.org/wiki/Rainbow_attack">???????? ??????</link>.
-</note>
+? ?????, ????? ??????????? ?? ??????????? ??????????).
 </listitem>
 
 </list>
 </para>
 
+<para>
+???? ??????? ??? ????????????????? ??????? ??????????? ????? ???? ?????????????
+? ??????? ??????? ?<command>openssl passwd</command>?, ????????:
+
+<example>
+$ openssl passwd -apr1 secret
+$apr1$x/muFo1c$zwUN24M2TEq.6wg0AZacn0
+</example>
+<example>
+$ openssl passwd -6 secret
+$6$FjZ1ss8ytcGmrGFY$1fopTJLuLUGCRlv2YcRPIsZk9uaD9NBOGcKsUay/BLV3RR1ol0ONS08oPTVqA4XBkZ44M7OL4K6NjP9xPKShP0
+</example>
+</para>
+
+<para>
+??? ?????? ?????? ??????????? ??????? ??????? ?????????, ???
+HTTP Basic Authentication ????????????? ???????? ?????? ??? ?????? ???????.
+</para>
+
 </directive>
 
 </section>

From mdounin at mdounin.ru  Tue Sep  3 10:18:46 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:46 +0300
Subject: [nginx-site] Documented charset_types changes.
Message-ID: <hg.ddf686b02ceb.1725358726.6391938264800526509@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/ddf686b02ceb
branches:  
changeset: 3096:ddf686b02ceb
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Mon Sep 02 09:35:06 2024 +0300
description:
Documented charset_types changes.

diffstat:

 xml/en/docs/http/ngx_http_charset_module.xml |  12 ++++++++----
 xml/ru/docs/http/ngx_http_charset_module.xml |  10 +++++++---
 2 files changed, 15 insertions(+), 7 deletions(-)

diffs (72 lines):

diff --git a/xml/en/docs/http/ngx_http_charset_module.xml b/xml/en/docs/http/ngx_http_charset_module.xml
--- a/xml/en/docs/http/ngx_http_charset_module.xml
+++ b/xml/en/docs/http/ngx_http_charset_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_charset_module"
         link="/en/docs/http/ngx_http_charset_module.html"
         lang="en"
-        rev="5">
+        rev="6">
 
 <section id="summary">
 
@@ -165,8 +165,8 @@ are provided in the distribution files <
 
 <directive name="charset_types">
 <syntax><value>mime-type</value> ...</syntax>
-<default>text/html text/xml text/plain text/vnd.wap.wml
-application/javascript application/rss+xml</default>
+<default>text/html text/xml text/javascript text/plain text/markdown
+text/vnd.wap.wml application/javascript application/rss+xml</default>
 <context>http</context>
 <context>server</context>
 <context>location</context>
@@ -180,9 +180,13 @@ The special value ?<literal>*</literal>? matches any MIME type (0.8.29).
 
 <para>
 <note>
-Until version 1.5.4, ?<literal>application/x-javascript</literal>? was used
+Prior to version 1.5.4, ?<literal>application/x-javascript</literal>? was used
 as the default MIME type instead of ?<literal>application/javascript</literal>?.
 </note>
+<note>
+Prior to version 1.27.4, the default value did not include
+?<literal>text/javascript</literal>? and ?<literal>text/markdown</literal>?.
+</note>
 </para>
 
 </directive>
diff --git a/xml/ru/docs/http/ngx_http_charset_module.xml b/xml/ru/docs/http/ngx_http_charset_module.xml
--- a/xml/ru/docs/http/ngx_http_charset_module.xml
+++ b/xml/ru/docs/http/ngx_http_charset_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_charset_module"
         link="/ru/docs/http/ngx_http_charset_module.html"
         lang="ru"
-        rev="5">
+        rev="6">
 
 <section id="summary">
 
@@ -164,8 +164,8 @@ charset_map koi8-r utf-8 {
 
 <directive name="charset_types">
 <syntax><value>mime-???</value> ...</syntax>
-<default>text/html text/xml text/plain text/vnd.wap.wml
-application/javascript application/rss+xml</default>
+<default>text/html text/xml text/javascript text/plain text/markdown
+text/vnd.wap.wml application/javascript application/rss+xml</default>
 <context>http</context>
 <context>server</context>
 <context>location</context>
@@ -184,6 +184,10 @@ application/javascript application/rss+x
 ?<literal>application/javascript</literal>? ?????????????
 ?<literal>application/x-javascript</literal>?.
 </note>
+<note>
+?? ?????? 1.27.4 ???????? ?? ????????? ?? ????????
+?<literal>text/javascript</literal>? ? ?<literal>text/markdown</literal>?.
+</note>
 </para>
 
 </directive>

From mdounin at mdounin.ru  Tue Sep  3 10:18:46 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:46 +0300
Subject: [nginx-site] Documented the $ssl_client_fingerprint_sha256 varia...
Message-ID: <hg.807f064844a5.1725358726.6391938264800526509@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/807f064844a5
branches:  
changeset: 3097:807f064844a5
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Mon Sep 02 09:49:53 2024 +0300
description:
Documented the $ssl_client_fingerprint_sha256 variable.

diffstat:

 xml/en/docs/http/ngx_http_ssl_module.xml     |  8 +++++++-
 xml/en/docs/stream/ngx_stream_ssl_module.xml |  8 +++++++-
 xml/ru/docs/http/ngx_http_ssl_module.xml     |  8 +++++++-
 xml/ru/docs/stream/ngx_stream_ssl_module.xml |  8 +++++++-
 4 files changed, 28 insertions(+), 4 deletions(-)

diffs (100 lines):

diff --git a/xml/en/docs/http/ngx_http_ssl_module.xml b/xml/en/docs/http/ngx_http_ssl_module.xml
--- a/xml/en/docs/http/ngx_http_ssl_module.xml
+++ b/xml/en/docs/http/ngx_http_ssl_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_http_ssl_module"
         link="/en/docs/http/ngx_http_ssl_module.html"
         lang="en"
-        rev="63">
+        rev="64">
 
 <section id="summary">
 
@@ -1059,6 +1059,12 @@ returns the SHA1 fingerprint of the clie
 for an established SSL connection (1.7.1);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+returns the SHA256 fingerprint of the client certificate
+for an established SSL connection (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 returns the ?issuer?DN? string of the client certificate
diff --git a/xml/en/docs/stream/ngx_stream_ssl_module.xml b/xml/en/docs/stream/ngx_stream_ssl_module.xml
--- a/xml/en/docs/stream/ngx_stream_ssl_module.xml
+++ b/xml/en/docs/stream/ngx_stream_ssl_module.xml
@@ -9,7 +9,7 @@
 <module name="Module ngx_stream_ssl_module"
         link="/en/docs/stream/ngx_stream_ssl_module.html"
         lang="en"
-        rev="32">
+        rev="33">
 
 <section id="summary">
 
@@ -716,6 +716,12 @@ returns the SHA1 fingerprint of the clie
 for an established SSL connection (1.11.8);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+returns the SHA256 fingerprint of the client certificate
+for an established SSL connection (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 returns the ?issuer?DN? string of the client certificate
diff --git a/xml/ru/docs/http/ngx_http_ssl_module.xml b/xml/ru/docs/http/ngx_http_ssl_module.xml
--- a/xml/ru/docs/http/ngx_http_ssl_module.xml
+++ b/xml/ru/docs/http/ngx_http_ssl_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_http_ssl_module"
         link="/ru/docs/http/ngx_http_ssl_module.html"
         lang="ru"
-        rev="63">
+        rev="64">
 
 <section id="summary">
 
@@ -1066,6 +1066,12 @@ AES128-SHA:AES256-SHA:0x00ff
 ??? ?????????????? SSL-?????????? (1.7.1);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+?????????? SHA256-????????? ??????????? ???????????
+??? ?????????????? SSL-?????????? (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 ?????????? ?????? ?issuer?DN? ??????????? ???????????
diff --git a/xml/ru/docs/stream/ngx_stream_ssl_module.xml b/xml/ru/docs/stream/ngx_stream_ssl_module.xml
--- a/xml/ru/docs/stream/ngx_stream_ssl_module.xml
+++ b/xml/ru/docs/stream/ngx_stream_ssl_module.xml
@@ -9,7 +9,7 @@
 <module name="?????? ngx_stream_ssl_module"
         link="/ru/docs/stream/ngx_stream_ssl_module.html"
         lang="ru"
-        rev="32">
+        rev="33">
 
 <section id="summary">
 
@@ -721,6 +721,12 @@ AES128-SHA:AES256-SHA:0x00ff
 ??? ?????????????? SSL-?????????? (1.11.8);
 </tag-desc>
 
+<tag-name id="var_ssl_client_fingerprint_sha256"><var>$ssl_client_fingerprint_sha256</var></tag-name>
+<tag-desc>
+?????????? SHA256-????????? ??????????? ???????????
+??? ?????????????? SSL-?????????? (1.27.4);
+</tag-desc>
+
 <tag-name id="var_ssl_client_i_dn"><var>$ssl_client_i_dn</var></tag-name>
 <tag-desc>
 ?????????? ?????? ?issuer?DN? ??????????? ???????????

From mdounin at mdounin.ru  Tue Sep  3 10:18:47 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:47 +0300
Subject: [nginx-site] Documented Auth-SSL-Fingerprint-SHA256 in mail proxy.
Message-ID: <hg.400dfceb9aff.1725358727.6391938264800526509@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/400dfceb9aff
branches:  
changeset: 3098:400dfceb9aff
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Mon Sep 02 10:08:59 2024 +0300
description:
Documented Auth-SSL-Fingerprint-SHA256 in mail proxy.

diffstat:

 xml/en/docs/mail/ngx_mail_auth_http_module.xml |  6 ++++--
 xml/ru/docs/mail/ngx_mail_auth_http_module.xml |  6 ++++--
 2 files changed, 8 insertions(+), 4 deletions(-)

diffs (60 lines):

diff --git a/xml/en/docs/mail/ngx_mail_auth_http_module.xml b/xml/en/docs/mail/ngx_mail_auth_http_module.xml
--- a/xml/en/docs/mail/ngx_mail_auth_http_module.xml
+++ b/xml/en/docs/mail/ngx_mail_auth_http_module.xml
@@ -10,7 +10,7 @@
 <module name="Module ngx_mail_auth_http_module"
         link="/en/docs/mail/ngx_mail_auth_http_module.html"
         lang="en"
-        rev="12">
+        rev="13">
 
 <section id="directives" name="Directives">
 
@@ -229,7 +229,8 @@ did not contain the <value>reason</value
 When the client certificate was present,
 its details are passed in the following request headers:
 <header>Auth-SSL-Subject</header>, <header>Auth-SSL-Issuer</header>,
-<header>Auth-SSL-Serial</header>, and <header>Auth-SSL-Fingerprint</header>.
+<header>Auth-SSL-Serial</header>, <header>Auth-SSL-Fingerprint</header>,
+and <header>Auth-SSL-Fingerprint-SHA256</header> (1.27.4).
 If <link id="auth_http_pass_client_cert"/> is enabled,
 the certificate itself is passed in the
 <header>Auth-SSL-Cert</header> header.
@@ -254,6 +255,7 @@ Auth-SSL-Subject: /CN=example.com
 Auth-SSL-Issuer: /CN=example.com
 Auth-SSL-Serial: C07AD56B846B5BFF
 Auth-SSL-Fingerprint: 29d6a80a123d13355ed16b4b04605e29cb55a5ad
+Auth-SSL-Fingerprint-SHA256: 8b489b945bd45dd8e229e40f4e9bbc2ee13c70dd82831e197e4084bccc0476d2
 </example>
 </para>
 
diff --git a/xml/ru/docs/mail/ngx_mail_auth_http_module.xml b/xml/ru/docs/mail/ngx_mail_auth_http_module.xml
--- a/xml/ru/docs/mail/ngx_mail_auth_http_module.xml
+++ b/xml/ru/docs/mail/ngx_mail_auth_http_module.xml
@@ -10,7 +10,7 @@
 <module name="?????? ngx_mail_auth_http_module"
         link="/ru/docs/mail/ngx_mail_auth_http_module.html"
         lang="ru"
-        rev="12">
+        rev="13">
 
 <section id="directives" name="?????????">
 
@@ -227,7 +227,8 @@ url="https://developers.google.com/gmail
 ???? ?????????? ?????????? ??? ????????????,
 ?????????? ? ??? ?????????? ? ????????? ?????????? ???????:
 <header>Auth-SSL-Subject</header>, <header>Auth-SSL-Issuer</header>,
-<header>Auth-SSL-Serial</header> ? <header>Auth-SSL-Fingerprint</header>.
+<header>Auth-SSL-Serial</header>, <header>Auth-SSL-Fingerprint</header>
+? <header>Auth-SSL-Fingerprint-SHA256</header> (1.27.4).
 ???? ????????? <link id="auth_http_pass_client_cert"/> ????????,
 ??? ?????????? ?????????? ? ?????????
 <header>Auth-SSL-Cert</header>.
@@ -252,6 +253,7 @@ Auth-SSL-Subject: /CN=example.com
 Auth-SSL-Issuer: /CN=example.com
 Auth-SSL-Serial: C07AD56B846B5BFF
 Auth-SSL-Fingerprint: 29d6a80a123d13355ed16b4b04605e29cb55a5ad
+Auth-SSL-Fingerprint-SHA256: 8b489b945bd45dd8e229e40f4e9bbc2ee13c70dd82831e197e4084bccc0476d2
 </example>
 </para>
 

From mdounin at mdounin.ru  Tue Sep  3 10:18:47 2024
From: mdounin at mdounin.ru (=?iso-8859-1?q?Maxim_Dounin?=)
Date: Tue, 03 Sep 2024 13:18:47 +0300
Subject: [nginx-site] freenginx-1.27.4
Message-ID: <hg.9cfda14d0109.1725358727.6391938264800526509@ns3.mdounin.ru>

details:   http://freenginx.org/hg/nginx-site/rev/9cfda14d0109
branches:  
changeset: 3099:9cfda14d0109
user:      Maxim Dounin <mdounin at mdounin.ru>
date:      Tue Sep 03 13:15:18 2024 +0300
description:
freenginx-1.27.4

diffstat:

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

diffs (87 lines):

diff --git a/text/en/CHANGES b/text/en/CHANGES
--- a/text/en/CHANGES
+++ b/text/en/CHANGES
@@ -1,4 +1,25 @@
 
+Changes with freenginx 1.27.4                                    03 Sep 2024
+
+    *) Feature: the $ssl_client_fingerprint_sha256 variable.
+
+    *) Feature: the "Auth-SSL-Fingerprint-SHA256 header line is now passed
+       to the mail proxy authentication server.
+
+    *) Change: MIME type for the "js" extension has been changed to
+       "text/javascript", the "mjs" extension now uses the "text/javascript"
+       MIME type, and the "md" and "markdown" extensions now use the
+       "text/markdown" MIME type; the default value of the "charset_types"
+       directive now includes "text/javascript" and "text/markdown".
+
+    *) Bugfix: a segmentation fault might occur in a worker process if the
+       ngx_http_mp4_module was used; the bug had appeared in 1.5.13.
+
+    *) Bugfix: a segmentation fault might occur in a worker process when
+       handling requests with the "Expect: 100-continue" request header
+       line; the bug had appeared in 1.27.0.
+
+
 Changes with freenginx 1.27.3                                    13 Aug 2024
 
     *) Change: now the "Age" backend response header line is taken into
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,26 @@
 
+????????? ? freenginx 1.27.4                                      03.09.2024
+
+    *) ??????????: ?????????? $ssl_client_fingerprint_sha256.
+
+    *) ??????????: ?????? ??????? ?????????????? ????????? ??????-???????
+       ?????????? ?????? ????????? "Auth-SSL-Fingerprint-SHA256".
+
+    *) ?????????: MIME-??? ??? ?????????? js ??????? ?? "text/javascript",
+       ??? ?????????? mjs ?????? ???????????? ??? "text/javascript", ???
+       ?????????? md ? markdown ?????? ???????????? ??? "text/markdown";
+       ???????? ?? ????????? ????????? charset_types ?????? ????????
+       "text/javascript" ? "text/markdown".
+
+    *) ???????????: ? ??????? ???????? ??? ????????? segmentation fault,
+       ???? ????????????? ?????? ngx_http_mp4_module; ?????? ????????? ?
+       1.5.13.
+
+    *) ???????????: ??? ????????? ???????? ?? ??????? "Expect: 100-continue"
+       ? ????????? ??????? ? ??????? ???????? ??? ????????? segmentation
+       fault; ?????? ????????? ? 1.27.0.
+
+
 ????????? ? freenginx 1.27.3                                      13.08.2024
 
     *) ?????????: ?????? ??? ??????????? ??????????? ?????? "Age" ?????????
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="2024-09-03">
+<para>
+<link doc="en/download.xml">freenginx-1.27.4</link>
+mainline version has been released.
+</para>
+</event>
+
 <event date="2024-08-13">
 <para>
 <link doc="en/download.xml">freenginx-1.27.3</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.27.4" name="freenginx" />
 <item ver="1.27.3" name="freenginx" />
 <item ver="1.27.2" name="freenginx" />
 <item ver="1.27.1" name="freenginx" />

From lafiel at elven.pw  Thu Sep  5 14:10:16 2024
From: lafiel at elven.pw (Lafiel)
Date: Thu, 05 Sep 2024 17:10:16 +0300
Subject: [nginx] Update mime-types
In-Reply-To: <ZdlN9mjsSgsQvaw8@mdounin.ru>
References: <6fd7b4aae9f284157bcd51b2eb936b82@elven.pw>
 <ZdlN9mjsSgsQvaw8@mdounin.ru>
Message-ID: <33cf12d6a7440f5538c60d38ff208870@elven.pw>

Hello!

Add 
new 
commits.


-- 
Best 
regards,
Lafiel
mailto:lafiel at elven.pw
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mime_types_04.patch
Type: text/x-diff
Size: 10206 bytes
Desc: not available
URL: <http://freenginx.org/pipermail/nginx-devel/attachments/20240905/1569bf9f/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xFAB0C3D2.asc
Type: application/pgp-keys
Size: 1461 bytes
Desc: not available
URL: <http://freenginx.org/pipermail/nginx-devel/attachments/20240905/1569bf9f/attachment.asc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://freenginx.org/pipermail/nginx-devel/attachments/20240905/1569bf9f/attachment.sig>

From hawkinsw at obs.cr  Fri Sep 13 05:20:34 2024
From: hawkinsw at obs.cr (=?iso-8859-1?q?Will_Hawkins?=)
Date: Fri, 13 Sep 2024 01:20:34 -0400
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <patchbomb.1726204833@ininer.rhod.uc.edu>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
Message-ID: <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>

# HG changeset patch
# User Will Hawkins <hawkinsw at obs.cr>
# Date 1726202944 14400
#      Fri Sep 13 00:49:04 2024 -0400
# Node ID 5bfd931f3b9641b51344d437207134f094012de5
# Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request

A handler that invokes ngx_http_finalize_request with NGX_DECLINED
causes an infinite loop because the phase handler index is not
incremented before restarting the processing of phases.

In (almost) all the other instances where a handler can return
NGX_DECLINED, the phase handler index is incremented before restarting
the processing of phases.

This change adds that index increment where it was missing.

diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
--- a/src/http/ngx_http_request.c	Tue Sep 03 13:11:25 2024 +0300
+++ b/src/http/ngx_http_request.c	Fri Sep 13 00:49:04 2024 -0400
@@ -2519,6 +2519,7 @@
     if (rc == NGX_DECLINED) {
         r->content_handler = NULL;
         r->write_event_handler = ngx_http_core_run_phases;
+        r->phase_handler++;
         ngx_http_core_run_phases(r);
         return;
     }


From hawkinsw at obs.cr  Fri Sep 13 05:20:33 2024
From: hawkinsw at obs.cr (=?iso-8859-1?q?Will_Hawkins?=)
Date: Fri, 13 Sep 2024 01:20:33 -0400
Subject: [PATCH 0 of 1] Fix infinite loop on NGX_DECLINED
Message-ID: <patchbomb.1726204833@ininer.rhod.uc.edu>

Hello Maxim (and community)!

First, I am a huge fan of freenginx. I have switched all my installations
to use freenginx and support your tremendous effort to protect the community.

I was writing a module when I noticed that using NGX_DECLINED as the rc
when calling ngx_http_finalize_request causes an infinite loop because
the phase handler index is not updated before phase processing is resumed.

A simple one-line change seems to fix the problem. I have prepared a patch
and tried very hard to make sure that I followed all the rules for contributing.
That said, I am sure that I missed a step or did something wrong.

If the patch is helpful but needs changes, please let me know -- I would be
more than happy to get things fixed up appropriately.

I have run all tests with the patch applied and everything seems to pass.

Thank you, again, for all that you do.


From mdounin at mdounin.ru  Fri Sep 13 15:32:53 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Fri, 13 Sep 2024 18:32:53 +0300
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
 <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
Message-ID: <ZuRbJXqeJx-7TT9_@mdounin.ru>

Hello!

On Fri, Sep 13, 2024 at 01:20:34AM -0400, Will Hawkins wrote:

> # HG changeset patch
> # User Will Hawkins <hawkinsw at obs.cr>
> # Date 1726202944 14400
> #      Fri Sep 13 00:49:04 2024 -0400
> # Node ID 5bfd931f3b9641b51344d437207134f094012de5
> # Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
> HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request
> 
> A handler that invokes ngx_http_finalize_request with NGX_DECLINED
> causes an infinite loop because the phase handler index is not
> incremented before restarting the processing of phases.
> 
> In (almost) all the other instances where a handler can return
> NGX_DECLINED, the phase handler index is incremented before restarting
> the processing of phases.
> 
> This change adds that index increment where it was missing.
> 
> diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
> --- a/src/http/ngx_http_request.c	Tue Sep 03 13:11:25 2024 +0300
> +++ b/src/http/ngx_http_request.c	Fri Sep 13 00:49:04 2024 -0400
> @@ -2519,6 +2519,7 @@
>      if (rc == NGX_DECLINED) {
>          r->content_handler = NULL;
>          r->write_event_handler = ngx_http_core_run_phases;
> +        r->phase_handler++;
>          ngx_http_core_run_phases(r);
>          return;
>      }
> 

The ngx_http_finalize_request(NGX_DECLINED) call (or return 
NGX_DECLINED) is expected to be used by location content handlers, 
as set by r->content_handler (clcf->handler), to switch back to 
phase handlers.  Note that it clears r->content_handler, so 
ngx_http_core_content_phase() will resume normal content phase 
processing.

For example, perl module does this when you return NGX_DECLINED 
from the perl code.

And incrementing r->phase_handler will certainly screw up things for 
this use case.

Could you please clarify why you think that calling 
ngx_http_finalize_request(NGX_DECLINED) in other cases might be 
needed, and not a bug in the module which does this?

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

From hawkinsw at obs.cr  Fri Sep 13 22:11:31 2024
From: hawkinsw at obs.cr (Will Hawkins)
Date: Fri, 13 Sep 2024 18:11:31 -0400
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <ZuRbJXqeJx-7TT9_@mdounin.ru>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
 <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
 <ZuRbJXqeJx-7TT9_@mdounin.ru>
Message-ID: <CADx9qWjAMYNu7euePR0_TZFwGAKgPTE+Sg8+Ngor=_-zZv+h+A@mail.gmail.com>

On Fri, Sep 13, 2024 at 11:32?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Fri, Sep 13, 2024 at 01:20:34AM -0400, Will Hawkins wrote:
>
> > # HG changeset patch
> > # User Will Hawkins <hawkinsw at obs.cr>
> > # Date 1726202944 14400
> > #      Fri Sep 13 00:49:04 2024 -0400
> > # Node ID 5bfd931f3b9641b51344d437207134f094012de5
> > # Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
> > HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request
> >
> > A handler that invokes ngx_http_finalize_request with NGX_DECLINED
> > causes an infinite loop because the phase handler index is not
> > incremented before restarting the processing of phases.
> >
> > In (almost) all the other instances where a handler can return
> > NGX_DECLINED, the phase handler index is incremented before restarting
> > the processing of phases.
> >
> > This change adds that index increment where it was missing.
> >
> > diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
> > --- a/src/http/ngx_http_request.c     Tue Sep 03 13:11:25 2024 +0300
> > +++ b/src/http/ngx_http_request.c     Fri Sep 13 00:49:04 2024 -0400
> > @@ -2519,6 +2519,7 @@
> >      if (rc == NGX_DECLINED) {
> >          r->content_handler = NULL;
> >          r->write_event_handler = ngx_http_core_run_phases;
> > +        r->phase_handler++;
> >          ngx_http_core_run_phases(r);
> >          return;
> >      }
> >
>
> The ngx_http_finalize_request(NGX_DECLINED) call (or return
> NGX_DECLINED) is expected to be used by location content handlers,
> as set by r->content_handler (clcf->handler), to switch back to
> phase handlers.  Note that it clears r->content_handler, so
> ngx_http_core_content_phase() will resume normal content phase
> processing.
>
> For example, perl module does this when you return NGX_DECLINED
> from the perl code.
>
> And incrementing r->phase_handler will certainly screw up things for
> this use case.
>
> Could you please clarify why you think that calling
> ngx_http_finalize_request(NGX_DECLINED) in other cases might be
> needed, and not a bug in the module which does this?
>

Thank you for the explanation!

After further reflection, I realized that my module was attempting to
incorrectly participate in the "ecosystem". I was writing my module to
be a (core) content handler rather than a location content handler. I
was doing this in an attempt to make it possible for my content
handler to give an NGX_DECLINED with the effect of giving "other"
content handlers a chance to respond. As I understand it, with
location content handlers, only one is allowed. I tried a
configuration with my module active and 'empty_gif;' and their
relative order in the location block affected which module was deemed
the content handler for that block.

It would be cool if there were a way for the module author to chain
location handlers.

I suppose that is not out of the realm of possibility but each module
would have to implement it themselves, it seems. A module could store
the existing value of the location content handler during execution of
the function for handling configuration information. Then, when their
handler is invoked, they could immediately dispatch to the stored
content handler in the case that they wanted to decline
responsibility.

Thank you again for the helpful response and sorry for wasting your time!
Will

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

From mdounin at mdounin.ru  Sun Sep 15 03:13:19 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 15 Sep 2024 06:13:19 +0300
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <CADx9qWjAMYNu7euePR0_TZFwGAKgPTE+Sg8+Ngor=_-zZv+h+A@mail.gmail.com>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
 <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
 <ZuRbJXqeJx-7TT9_@mdounin.ru>
 <CADx9qWjAMYNu7euePR0_TZFwGAKgPTE+Sg8+Ngor=_-zZv+h+A@mail.gmail.com>
Message-ID: <ZuZQzyaLTMXGCsFL@mdounin.ru>

Hello!

On Fri, Sep 13, 2024 at 06:11:31PM -0400, Will Hawkins wrote:

> On Fri, Sep 13, 2024 at 11:32?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > Hello!
> >
> > On Fri, Sep 13, 2024 at 01:20:34AM -0400, Will Hawkins wrote:
> >
> > > # HG changeset patch
> > > # User Will Hawkins <hawkinsw at obs.cr>
> > > # Date 1726202944 14400
> > > #      Fri Sep 13 00:49:04 2024 -0400
> > > # Node ID 5bfd931f3b9641b51344d437207134f094012de5
> > > # Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
> > > HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request
> > >
> > > A handler that invokes ngx_http_finalize_request with NGX_DECLINED
> > > causes an infinite loop because the phase handler index is not
> > > incremented before restarting the processing of phases.
> > >
> > > In (almost) all the other instances where a handler can return
> > > NGX_DECLINED, the phase handler index is incremented before restarting
> > > the processing of phases.
> > >
> > > This change adds that index increment where it was missing.
> > >
> > > diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
> > > --- a/src/http/ngx_http_request.c     Tue Sep 03 13:11:25 2024 +0300
> > > +++ b/src/http/ngx_http_request.c     Fri Sep 13 00:49:04 2024 -0400
> > > @@ -2519,6 +2519,7 @@
> > >      if (rc == NGX_DECLINED) {
> > >          r->content_handler = NULL;
> > >          r->write_event_handler = ngx_http_core_run_phases;
> > > +        r->phase_handler++;
> > >          ngx_http_core_run_phases(r);
> > >          return;
> > >      }
> > >
> >
> > The ngx_http_finalize_request(NGX_DECLINED) call (or return
> > NGX_DECLINED) is expected to be used by location content handlers,
> > as set by r->content_handler (clcf->handler), to switch back to
> > phase handlers.  Note that it clears r->content_handler, so
> > ngx_http_core_content_phase() will resume normal content phase
> > processing.
> >
> > For example, perl module does this when you return NGX_DECLINED
> > from the perl code.
> >
> > And incrementing r->phase_handler will certainly screw up things for
> > this use case.
> >
> > Could you please clarify why you think that calling
> > ngx_http_finalize_request(NGX_DECLINED) in other cases might be
> > needed, and not a bug in the module which does this?
> >
> 
> Thank you for the explanation!
> 
> After further reflection, I realized that my module was attempting to
> incorrectly participate in the "ecosystem". I was writing my module to
> be a (core) content handler rather than a location content handler. I
> was doing this in an attempt to make it possible for my content
> handler to give an NGX_DECLINED with the effect of giving "other"
> content handlers a chance to respond. As I understand it, with
> location content handlers, only one is allowed. I tried a
> configuration with my module active and 'empty_gif;' and their
> relative order in the location block affected which module was deemed
> the content handler for that block.
> 
> It would be cool if there were a way for the module author to chain
> location handlers.
> 
> I suppose that is not out of the realm of possibility but each module
> would have to implement it themselves, it seems. A module could store
> the existing value of the location content handler during execution of
> the function for handling configuration information. Then, when their
> handler is invoked, they could immediately dispatch to the stored
> content handler in the case that they wanted to decline
> responsibility.

Not sure what exactly you are trying to do, but if you consider 
chaining your module with other modules, content phase handler 
might be more appropriate.  Alternatively, a location content 
handler which generates an error for requests it cannot handle 
might be an option, so it would be possible to configure 
error_page processing if needed.

In general there are two types of content handlers:

1. Content phase handlers, such as in the dav, index, autoindex, 
and static modules.  Such modules are configured globally, and 
settings are inherited into more specific contexts, such as 
locations or nested locations.  These modules can decline the 
request by returning NGX_DECLINED from the handler, so the request 
processing is passed to the next content phase handler.

2. Location content handlers, as set by clcf->handler, such as 
empty_gif, proxy_pass, mp4, and perl.   This can be seen as 
"simple" content handlers.  Such modules are activated exclusively 
for a particular location and not inherited into nested contexts.  
And they are not expected to be chained.  Still, such modules can 
decline the request by returning NGX_DECLINED from the handler or 
by calling ngx_http_finalize_request(NGX_DECLINED) at some point 
later (such as after reading the request body), so phase 
processing is resumed and the request is further handled by 
content phase handlers.

Depending on what you are trying to implement and how do you 
expect it to be configured, both content phase handlers and 
location content handlers might be appropriate.

Chaining location content handlers is not supported, and trying to 
configure more than one location content handler in a location is 
basically a configuration error: for example, you cannot have both 
"empty_gif" and "proxy_pass" in a location at the same time, as 
both modules are expected to handle all requests in the location.

Further, trying to support such chaining for location content 
handlers which handle only some of the requests might not be a 
good idea, since the resulting behaviour will depend on the order 
of the relevant directives, which is not generally expected from a 
declarative configuration (there are few exceptions, such as 
regular expressions and rewrite module instructions, but in general 
order of the directives is not important).  Rather, if chaining is 
needed, using content phase handlers might be a better option - so 
the order of processing by different modules is well known.

Hope this helps.

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

From hawkinsw at obs.cr  Sun Sep 15 03:46:09 2024
From: hawkinsw at obs.cr (Will Hawkins)
Date: Sat, 14 Sep 2024 23:46:09 -0400
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <ZuZQzyaLTMXGCsFL@mdounin.ru>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
 <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
 <ZuRbJXqeJx-7TT9_@mdounin.ru>
 <CADx9qWjAMYNu7euePR0_TZFwGAKgPTE+Sg8+Ngor=_-zZv+h+A@mail.gmail.com>
 <ZuZQzyaLTMXGCsFL@mdounin.ru>
Message-ID: <CADx9qWjJ9FVcF4yxCNWjG4Sz_9qrMW70+FpoYkQAL6bRAW9iDA@mail.gmail.com>

On Sat, Sep 14, 2024 at 11:13?PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Fri, Sep 13, 2024 at 06:11:31PM -0400, Will Hawkins wrote:
>
> > On Fri, Sep 13, 2024 at 11:32?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> > >
> > > Hello!
> > >
> > > On Fri, Sep 13, 2024 at 01:20:34AM -0400, Will Hawkins wrote:
> > >
> > > > # HG changeset patch
> > > > # User Will Hawkins <hawkinsw at obs.cr>
> > > > # Date 1726202944 14400
> > > > #      Fri Sep 13 00:49:04 2024 -0400
> > > > # Node ID 5bfd931f3b9641b51344d437207134f094012de5
> > > > # Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
> > > > HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request
> > > >
> > > > A handler that invokes ngx_http_finalize_request with NGX_DECLINED
> > > > causes an infinite loop because the phase handler index is not
> > > > incremented before restarting the processing of phases.
> > > >
> > > > In (almost) all the other instances where a handler can return
> > > > NGX_DECLINED, the phase handler index is incremented before restarting
> > > > the processing of phases.
> > > >
> > > > This change adds that index increment where it was missing.
> > > >
> > > > diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
> > > > --- a/src/http/ngx_http_request.c     Tue Sep 03 13:11:25 2024 +0300
> > > > +++ b/src/http/ngx_http_request.c     Fri Sep 13 00:49:04 2024 -0400
> > > > @@ -2519,6 +2519,7 @@
> > > >      if (rc == NGX_DECLINED) {
> > > >          r->content_handler = NULL;
> > > >          r->write_event_handler = ngx_http_core_run_phases;
> > > > +        r->phase_handler++;
> > > >          ngx_http_core_run_phases(r);
> > > >          return;
> > > >      }
> > > >
> > >
> > > The ngx_http_finalize_request(NGX_DECLINED) call (or return
> > > NGX_DECLINED) is expected to be used by location content handlers,
> > > as set by r->content_handler (clcf->handler), to switch back to
> > > phase handlers.  Note that it clears r->content_handler, so
> > > ngx_http_core_content_phase() will resume normal content phase
> > > processing.
> > >
> > > For example, perl module does this when you return NGX_DECLINED
> > > from the perl code.
> > >
> > > And incrementing r->phase_handler will certainly screw up things for
> > > this use case.
> > >
> > > Could you please clarify why you think that calling
> > > ngx_http_finalize_request(NGX_DECLINED) in other cases might be
> > > needed, and not a bug in the module which does this?
> > >
> >
> > Thank you for the explanation!
> >
> > After further reflection, I realized that my module was attempting to
> > incorrectly participate in the "ecosystem". I was writing my module to
> > be a (core) content handler rather than a location content handler. I
> > was doing this in an attempt to make it possible for my content
> > handler to give an NGX_DECLINED with the effect of giving "other"
> > content handlers a chance to respond. As I understand it, with
> > location content handlers, only one is allowed. I tried a
> > configuration with my module active and 'empty_gif;' and their
> > relative order in the location block affected which module was deemed
> > the content handler for that block.
> >
> > It would be cool if there were a way for the module author to chain
> > location handlers.
> >
> > I suppose that is not out of the realm of possibility but each module
> > would have to implement it themselves, it seems. A module could store
> > the existing value of the location content handler during execution of
> > the function for handling configuration information. Then, when their
> > handler is invoked, they could immediately dispatch to the stored
> > content handler in the case that they wanted to decline
> > responsibility.
>
> Not sure what exactly you are trying to do, but if you consider
> chaining your module with other modules, content phase handler
> might be more appropriate.  Alternatively, a location content
> handler which generates an error for requests it cannot handle
> might be an option, so it would be possible to configure
> error_page processing if needed.
>
> In general there are two types of content handlers:
>
> 1. Content phase handlers, such as in the dav, index, autoindex,
> and static modules.  Such modules are configured globally, and
> settings are inherited into more specific contexts, such as
> locations or nested locations.  These modules can decline the
> request by returning NGX_DECLINED from the handler, so the request
> processing is passed to the next content phase handler.

Thank you for the response! I really appreciate it. This was (is?)
exactly what I was trying to do. As I said, however, if the handler
cannot make the decision to handle the response until after reading
the body, it cannot return NGX_DECLINED from the handler. It would
have to return something else (e.g., NGX_OK) while waiting for the
callback given to ngx_http_read_client_request_body to execute to
examine the body. Then, inside that callback, the only option would be
to call ngx_http_finalize_request(NGX_DECLINED). At that point, we
would have the infinite loop that I experienced. That was one of the
reasons that I thought the fix I submitted would be helpful. In other
words, the kind of handler I am writing would not be working in a
situation where r->content_handler has a value.

So, would it be possible to have a second version of my proposed patch
that would change the relevant part of ngx_http_finalize_request to
look like:

if (rc == NGX_DECLINED) {
  if (r->content_handler == NULL) {
      r->phase_handler++;
  }
  r->content_handler = NULL;
  r->write_event_handler = ngx_http_core_run_phases;
  ngx_http_core_run_phases(r);
  return;
}

That might make possible both situations:
1. Preserve the existing behavior for location content handlers (like
the perl module the way that you mentioned)
2. Add support for returning NGX_DECLINED in content phase handlers.

If that seems reasonable, I would be more than happy to modify the
patch and submit!


>
> 2. Location content handlers, as set by clcf->handler, such as
> empty_gif, proxy_pass, mp4, and perl.   This can be seen as
> "simple" content handlers.  Such modules are activated exclusively
> for a particular location and not inherited into nested contexts.
> And they are not expected to be chained.  Still, such modules can
> decline the request by returning NGX_DECLINED from the handler or
> by calling ngx_http_finalize_request(NGX_DECLINED) at some point
> later (such as after reading the request body), so phase
> processing is resumed and the request is further handled by
> content phase handlers.
>
> Depending on what you are trying to implement and how do you
> expect it to be configured, both content phase handlers and
> location content handlers might be appropriate.
>
> Chaining location content handlers is not supported, and trying to
> configure more than one location content handler in a location is
> basically a configuration error: for example, you cannot have both
> "empty_gif" and "proxy_pass" in a location at the same time, as
> both modules are expected to handle all requests in the location.
>
> Further, trying to support such chaining for location content
> handlers which handle only some of the requests might not be a
> good idea, since the resulting behaviour will depend on the order

You are (of course!) absolutely correct! That would make for a
complicated situation that might result in surprising behavior.

Thank you, again, for all your feedback!
Will

> of the relevant directives, which is not generally expected from a
> declarative configuration (there are few exceptions, such as
> regular expressions and rewrite module instructions, but in general
> order of the directives is not important).  Rather, if chaining is
> needed, using content phase handlers might be a better option - so
> the order of processing by different modules is well known.
>
> Hope this helps.
>
> --
> Maxim Dounin
> http://mdounin.ru/

From mdounin at mdounin.ru  Sun Sep 15 04:50:23 2024
From: mdounin at mdounin.ru (Maxim Dounin)
Date: Sun, 15 Sep 2024 07:50:23 +0300
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <CADx9qWjJ9FVcF4yxCNWjG4Sz_9qrMW70+FpoYkQAL6bRAW9iDA@mail.gmail.com>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
 <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
 <ZuRbJXqeJx-7TT9_@mdounin.ru>
 <CADx9qWjAMYNu7euePR0_TZFwGAKgPTE+Sg8+Ngor=_-zZv+h+A@mail.gmail.com>
 <ZuZQzyaLTMXGCsFL@mdounin.ru>
 <CADx9qWjJ9FVcF4yxCNWjG4Sz_9qrMW70+FpoYkQAL6bRAW9iDA@mail.gmail.com>
Message-ID: <ZuZnj5W9Yu1_SbmF@mdounin.ru>

Hello!

On Sat, Sep 14, 2024 at 11:46:09PM -0400, Will Hawkins wrote:

> On Sat, Sep 14, 2024 at 11:13?PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> >
> > Hello!
> >
> > On Fri, Sep 13, 2024 at 06:11:31PM -0400, Will Hawkins wrote:
> >
> > > On Fri, Sep 13, 2024 at 11:32?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> > > >
> > > > Hello!
> > > >
> > > > On Fri, Sep 13, 2024 at 01:20:34AM -0400, Will Hawkins wrote:
> > > >
> > > > > # HG changeset patch
> > > > > # User Will Hawkins <hawkinsw at obs.cr>
> > > > > # Date 1726202944 14400
> > > > > #      Fri Sep 13 00:49:04 2024 -0400
> > > > > # Node ID 5bfd931f3b9641b51344d437207134f094012de5
> > > > > # Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
> > > > > HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request
> > > > >
> > > > > A handler that invokes ngx_http_finalize_request with NGX_DECLINED
> > > > > causes an infinite loop because the phase handler index is not
> > > > > incremented before restarting the processing of phases.
> > > > >
> > > > > In (almost) all the other instances where a handler can return
> > > > > NGX_DECLINED, the phase handler index is incremented before restarting
> > > > > the processing of phases.
> > > > >
> > > > > This change adds that index increment where it was missing.
> > > > >
> > > > > diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
> > > > > --- a/src/http/ngx_http_request.c     Tue Sep 03 13:11:25 2024 +0300
> > > > > +++ b/src/http/ngx_http_request.c     Fri Sep 13 00:49:04 2024 -0400
> > > > > @@ -2519,6 +2519,7 @@
> > > > >      if (rc == NGX_DECLINED) {
> > > > >          r->content_handler = NULL;
> > > > >          r->write_event_handler = ngx_http_core_run_phases;
> > > > > +        r->phase_handler++;
> > > > >          ngx_http_core_run_phases(r);
> > > > >          return;
> > > > >      }
> > > > >
> > > >
> > > > The ngx_http_finalize_request(NGX_DECLINED) call (or return
> > > > NGX_DECLINED) is expected to be used by location content handlers,
> > > > as set by r->content_handler (clcf->handler), to switch back to
> > > > phase handlers.  Note that it clears r->content_handler, so
> > > > ngx_http_core_content_phase() will resume normal content phase
> > > > processing.
> > > >
> > > > For example, perl module does this when you return NGX_DECLINED
> > > > from the perl code.
> > > >
> > > > And incrementing r->phase_handler will certainly screw up things for
> > > > this use case.
> > > >
> > > > Could you please clarify why you think that calling
> > > > ngx_http_finalize_request(NGX_DECLINED) in other cases might be
> > > > needed, and not a bug in the module which does this?
> > > >
> > >
> > > Thank you for the explanation!
> > >
> > > After further reflection, I realized that my module was attempting to
> > > incorrectly participate in the "ecosystem". I was writing my module to
> > > be a (core) content handler rather than a location content handler. I
> > > was doing this in an attempt to make it possible for my content
> > > handler to give an NGX_DECLINED with the effect of giving "other"
> > > content handlers a chance to respond. As I understand it, with
> > > location content handlers, only one is allowed. I tried a
> > > configuration with my module active and 'empty_gif;' and their
> > > relative order in the location block affected which module was deemed
> > > the content handler for that block.
> > >
> > > It would be cool if there were a way for the module author to chain
> > > location handlers.
> > >
> > > I suppose that is not out of the realm of possibility but each module
> > > would have to implement it themselves, it seems. A module could store
> > > the existing value of the location content handler during execution of
> > > the function for handling configuration information. Then, when their
> > > handler is invoked, they could immediately dispatch to the stored
> > > content handler in the case that they wanted to decline
> > > responsibility.
> >
> > Not sure what exactly you are trying to do, but if you consider
> > chaining your module with other modules, content phase handler
> > might be more appropriate.  Alternatively, a location content
> > handler which generates an error for requests it cannot handle
> > might be an option, so it would be possible to configure
> > error_page processing if needed.
> >
> > In general there are two types of content handlers:
> >
> > 1. Content phase handlers, such as in the dav, index, autoindex,
> > and static modules.  Such modules are configured globally, and
> > settings are inherited into more specific contexts, such as
> > locations or nested locations.  These modules can decline the
> > request by returning NGX_DECLINED from the handler, so the request
> > processing is passed to the next content phase handler.
> 
> Thank you for the response! I really appreciate it. This was (is?)
> exactly what I was trying to do. As I said, however, if the handler
> cannot make the decision to handle the response until after reading
> the body, it cannot return NGX_DECLINED from the handler. It would
> have to return something else (e.g., NGX_OK) while waiting for the
> callback given to ngx_http_read_client_request_body to execute to
> examine the body. Then, inside that callback, the only option would be
> to call ngx_http_finalize_request(NGX_DECLINED). At that point, we
> would have the infinite loop that I experienced. That was one of the
> reasons that I thought the fix I submitted would be helpful. In other
> words, the kind of handler I am writing would not be working in a
> situation where r->content_handler has a value.
> 
> So, would it be possible to have a second version of my proposed patch
> that would change the relevant part of ngx_http_finalize_request to
> look like:
> 
> if (rc == NGX_DECLINED) {
>   if (r->content_handler == NULL) {
>       r->phase_handler++;
>   }
>   r->content_handler = NULL;
>   r->write_event_handler = ngx_http_core_run_phases;
>   ngx_http_core_run_phases(r);
>   return;
> }
> 
> That might make possible both situations:
> 1. Preserve the existing behavior for location content handlers (like
> the perl module the way that you mentioned)
> 2. Add support for returning NGX_DECLINED in content phase handlers.
> 
> If that seems reasonable, I would be more than happy to modify the
> patch and submit!

The specific ngx_http_finalize_request(NGX_DECLINED) handling is 
for location content handlers.  While it probably can be extended 
to support content phase (since r->content_handler is expected to 
be NULL at the content phase), it won't work for other phases 
anyway.  (And the required code would be more complex, see 
ngx_http_core_content_phase() - it needs to check if there are 
additional content phase handlers, and return 403/404 if not.)

As such, I would rather recommend generic approach to resume phase 
processing, much like it is used in other phase handlers: restore 
ngx_http_core_run_phases() as a write handler, run it, and then 
return NGX_DECLINED from the handler.

(Note that just calling ngx_http_finalize_request(NGX_DECLINED) 
and then returning NGX_DECLINED from the handler would be mostly 
equivalent for a content phase handler, but I would rather 
recommend restoring ngx_http_core_run_phases explicitly.)

Examples can be seen in the limit_req and mirror modules.  The 
mirror module specifically reads the request body and can be used 
as a guidance on how to properly restore phase processing after 
reading the request body.

(Note though that the mirror module runs in the precontent phase, 
and therefore needs additional steps to properly pause phase 
processing; for a content phase handler, just

    rc = ngx_http_read_client_request_body(r, ngx_http_foo_handler);

    if (rc >= NGX_HTTP_SPECIAL_RESPONSE) {
        return rc;
    }

    return NGX_DONE;

as normally seen in content handlers would be the way to go.)

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

From hawkinsw at obs.cr  Sun Sep 15 19:50:42 2024
From: hawkinsw at obs.cr (Will Hawkins)
Date: Sun, 15 Sep 2024 15:50:42 -0400
Subject: [PATCH 1 of 1] HTTP: Fix infinite loop on NGX_DECLINED in
 ngx_http_finalize_request
In-Reply-To: <ZuZnj5W9Yu1_SbmF@mdounin.ru>
References: <patchbomb.1726204833@ininer.rhod.uc.edu>
 <5bfd931f3b9641b51344.1726204834@ininer.rhod.uc.edu>
 <ZuRbJXqeJx-7TT9_@mdounin.ru>
 <CADx9qWjAMYNu7euePR0_TZFwGAKgPTE+Sg8+Ngor=_-zZv+h+A@mail.gmail.com>
 <ZuZQzyaLTMXGCsFL@mdounin.ru>
 <CADx9qWjJ9FVcF4yxCNWjG4Sz_9qrMW70+FpoYkQAL6bRAW9iDA@mail.gmail.com>
 <ZuZnj5W9Yu1_SbmF@mdounin.ru>
Message-ID: <CADx9qWiQz1Mm61ib4jo-bhqRGAngxaXddRa+Sio+=CrvQtgK3A@mail.gmail.com>

On Sun, Sep 15, 2024 at 12:50?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Sat, Sep 14, 2024 at 11:46:09PM -0400, Will Hawkins wrote:
>
> > On Sat, Sep 14, 2024 at 11:13?PM Maxim Dounin <mdounin at mdounin.ru> wrote:
> > >
> > > Hello!
> > >
> > > On Fri, Sep 13, 2024 at 06:11:31PM -0400, Will Hawkins wrote:
> > >
> > > > On Fri, Sep 13, 2024 at 11:32?AM Maxim Dounin <mdounin at mdounin.ru> wrote:
> > > > >
> > > > > Hello!
> > > > >
> > > > > On Fri, Sep 13, 2024 at 01:20:34AM -0400, Will Hawkins wrote:
> > > > >
> > > > > > # HG changeset patch
> > > > > > # User Will Hawkins <hawkinsw at obs.cr>
> > > > > > # Date 1726202944 14400
> > > > > > #      Fri Sep 13 00:49:04 2024 -0400
> > > > > > # Node ID 5bfd931f3b9641b51344d437207134f094012de5
> > > > > > # Parent  dbf76fdd109fbbba40a7c5299cc277d180f4bbad
> > > > > > HTTP: Fix infinite loop on NGX_DECLINED in ngx_http_finalize_request
> > > > > >
> > > > > > A handler that invokes ngx_http_finalize_request with NGX_DECLINED
> > > > > > causes an infinite loop because the phase handler index is not
> > > > > > incremented before restarting the processing of phases.
> > > > > >
> > > > > > In (almost) all the other instances where a handler can return
> > > > > > NGX_DECLINED, the phase handler index is incremented before restarting
> > > > > > the processing of phases.
> > > > > >
> > > > > > This change adds that index increment where it was missing.
> > > > > >
> > > > > > diff -r dbf76fdd109f -r 5bfd931f3b96 src/http/ngx_http_request.c
> > > > > > --- a/src/http/ngx_http_request.c     Tue Sep 03 13:11:25 2024 +0300
> > > > > > +++ b/src/http/ngx_http_request.c     Fri Sep 13 00:49:04 2024 -0400
> > > > > > @@ -2519,6 +2519,7 @@
> > > > > >      if (rc == NGX_DECLINED) {
> > > > > >          r->content_handler = NULL;
> > > > > >          r->write_event_handler = ngx_http_core_run_phases;
> > > > > > +        r->phase_handler++;
> > > > > >          ngx_http_core_run_phases(r);
> > > > > >          return;
> > > > > >      }
> > > > > >
> > > > >
> > > > > The ngx_http_finalize_request(NGX_DECLINED) call (or return
> > > > > NGX_DECLINED) is expected to be used by location content handlers,
> > > > > as set by r->content_handler (clcf->handler), to switch back to
> > > > > phase handlers.  Note that it clears r->content_handler, so
> > > > > ngx_http_core_content_phase() will resume normal content phase
> > > > > processing.
> > > > >
> > > > > For example, perl module does this when you return NGX_DECLINED
> > > > > from the perl code.
> > > > >
> > > > > And incrementing r->phase_handler will certainly screw up things for
> > > > > this use case.
> > > > >
> > > > > Could you please clarify why you think that calling
> > > > > ngx_http_finalize_request(NGX_DECLINED) in other cases might be
> > > > > needed, and not a bug in the module which does this?
> > > > >
> > > >
> > > > Thank you for the explanation!
> > > >
> > > > After further reflection, I realized that my module was attempting to
> > > > incorrectly participate in the "ecosystem". I was writing my module to
> > > > be a (core) content handler rather than a location content handler. I
> > > > was doing this in an attempt to make it possible for my content
> > > > handler to give an NGX_DECLINED with the effect of giving "other"
> > > > content handlers a chance to respond. As I understand it, with
> > > > location content handlers, only one is allowed. I tried a
> > > > configuration with my module active and 'empty_gif;' and their
> > > > relative order in the location block affected which module was deemed
> > > > the content handler for that block.
> > > >
> > > > It would be cool if there were a way for the module author to chain
> > > > location handlers.
> > > >
> > > > I suppose that is not out of the realm of possibility but each module
> > > > would have to implement it themselves, it seems. A module could store
> > > > the existing value of the location content handler during execution of
> > > > the function for handling configuration information. Then, when their
> > > > handler is invoked, they could immediately dispatch to the stored
> > > > content handler in the case that they wanted to decline
> > > > responsibility.
> > >
> > > Not sure what exactly you are trying to do, but if you consider
> > > chaining your module with other modules, content phase handler
> > > might be more appropriate.  Alternatively, a location content
> > > handler which generates an error for requests it cannot handle
> > > might be an option, so it would be possible to configure
> > > error_page processing if needed.
> > >
> > > In general there are two types of content handlers:
> > >
> > > 1. Content phase handlers, such as in the dav, index, autoindex,
> > > and static modules.  Such modules are configured globally, and
> > > settings are inherited into more specific contexts, such as
> > > locations or nested locations.  These modules can decline the
> > > request by returning NGX_DECLINED from the handler, so the request
> > > processing is passed to the next content phase handler.
> >
> > Thank you for the response! I really appreciate it. This was (is?)
> > exactly what I was trying to do. As I said, however, if the handler
> > cannot make the decision to handle the response until after reading
> > the body, it cannot return NGX_DECLINED from the handler. It would
> > have to return something else (e.g., NGX_OK) while waiting for the
> > callback given to ngx_http_read_client_request_body to execute to
> > examine the body. Then, inside that callback, the only option would be
> > to call ngx_http_finalize_request(NGX_DECLINED). At that point, we
> > would have the infinite loop that I experienced. That was one of the
> > reasons that I thought the fix I submitted would be helpful. In other
> > words, the kind of handler I am writing would not be working in a
> > situation where r->content_handler has a value.
> >
> > So, would it be possible to have a second version of my proposed patch
> > that would change the relevant part of ngx_http_finalize_request to
> > look like:
> >
> > if (rc == NGX_DECLINED) {
> >   if (r->content_handler == NULL) {
> >       r->phase_handler++;
> >   }
> >   r->content_handler = NULL;
> >   r->write_event_handler = ngx_http_core_run_phases;
> >   ngx_http_core_run_phases(r);
> >   return;
> > }
> >
> > That might make possible both situations:
> > 1. Preserve the existing behavior for location content handlers (like
> > the perl module the way that you mentioned)
> > 2. Add support for returning NGX_DECLINED in content phase handlers.
> >
> > If that seems reasonable, I would be more than happy to modify the
> > patch and submit!
>
> The specific ngx_http_finalize_request(NGX_DECLINED) handling is
> for location content handlers.  While it probably can be extended
> to support content phase (since r->content_handler is expected to
> be NULL at the content phase), it won't work for other phases
> anyway.  (And the required code would be more complex, see
> ngx_http_core_content_phase() - it needs to check if there are
> additional content phase handlers, and return 403/404 if not.)
>
> As such, I would rather recommend generic approach to resume phase
> processing, much like it is used in other phase handlers: restore
> ngx_http_core_run_phases() as a write handler, run it, and then
> return NGX_DECLINED from the handler.
>
> (Note that just calling ngx_http_finalize_request(NGX_DECLINED)
> and then returning NGX_DECLINED from the handler would be mostly
> equivalent for a content phase handler, but I would rather
> recommend restoring ngx_http_core_run_phases explicitly.)
>
> Examples can be seen in the limit_req and mirror modules.  The
> mirror module specifically reads the request body and can be used
> as a guidance on how to properly restore phase processing after
> reading the request body.
>
> (Note though that the mirror module runs in the precontent phase,
> and therefore needs additional steps to properly pause phase
> processing; for a content phase handler, just
>
>     rc = ngx_http_read_client_request_body(r, ngx_http_foo_handler);
>
>     if (rc >= NGX_HTTP_SPECIAL_RESPONSE) {
>         return rc;
>     }
>
>     return NGX_DONE;
>
> as normally seen in content handlers would be the way to go.)
>

Thank you (again!) for the thorough response. I really appreciate it.
It might take me a day or two, but I would like to experiment with
preparing another version of the patch that incorporates your advice
by creating a function that would take the necessary steps to "fixup"
the request so that returning an NGX_DECLINED triggers processing in
the next phase.

Thank you again for the response!
Will

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