update reference.json

reference-lib/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nginx/reference-lib",
-  "version": "1.1.6",
+  "version": "1.1.7",
   "description": "",
   "main": "dist/index.js",
   "type": "module",

reference-lib/src/reference.json

@@ -184,7 +184,7 @@
           ],
           "isBlock": false,
           "description_md": "Specifies a file that keeps user names and passwords,\nin the following format:\n```\n# comment\nname1:password1\nname2:password2:comment\nname3:password3\n```\nThe *`file`* name can contain variables.\n\nThe following password types are supported:\n- encrypted with the `crypt()` function; can be generated using\n    the “`htpasswd`” utility from the Apache HTTP Server\n    distribution or the “`openssl passwd`” command;\n- hashed with the Apache variant of the MD5-based password algorithm (apr1);\n    can be generated with the same tools;\n- specified by the\n    “`{`*`scheme`*`}`*`data`*”\n    syntax (1.0.3+) as described in\n    [RFC 2307](https://datatracker.ietf.org/doc/html/rfc2307#section-5.3);\n    currently implemented schemes include `PLAIN` (an example one,\n    should not be used), `SHA` (1.3.13) (plain SHA-1\n    hashing, should not be used) and `SSHA` (salted SHA-1 hashing,\n    used by some software packages, notably OpenLDAP and Dovecot).\n    > Support for `SHA` scheme was added only to aid\n    > in migration from other web servers.\n    > It should not be used for new passwords, since unsalted SHA-1 hashing\n    > that it employs is vulnerable to\n    > [rainbow table](http://en.wikipedia.org/wiki/Rainbow_attack)\n    > attacks.",
-          "description_html": "<p>Specifies a file that keeps user names and passwords,\nin the following format:</p>\n\n<pre><code># comment\nname1:password1\nname2:password2:comment\nname3:password3\n</code></pre>\n\n<p>The <em><code>file</code></em> name can contain variables.</p>\n\n<p>The following password types are supported:</p>\n\n<ul>\n<li>encrypted with the <code>crypt()</code> function; can be generated using\nthe “<code>htpasswd</code>” utility from the Apache HTTP Server\ndistribution or the “<code>openssl passwd</code>” command;</li>\n<li>hashed with the Apache variant of the MD5-based password algorithm (apr1);\ncan be generated with the same tools;</li>\n<li>specified by the\n“<code>{</code><em><code>scheme</code></em><code>}</code>*<code>data</code>*”\nsyntax (1.0.3+) as described in\n<a href=\"https://datatracker.ietf.org/doc/html/rfc2307#section-5.3\" target=\"_blank\">RFC 2307</a>;\ncurrently implemented schemes include <code>PLAIN</code> (an example one,\nshould not be used), <code>SHA</code> (1.3.13) (plain SHA-1\nhashing, should not be used) and <code>SSHA</code> (salted SHA-1 hashing,\nused by some software packages, notably OpenLDAP and Dovecot).\n&gt; Support for <code>SHA</code> scheme was added only to aid\n&gt; in migration from other web servers.\n&gt; It should not be used for new passwords, since unsalted SHA-1 hashing\n&gt; that it employs is vulnerable to\n&gt; <a href=\"http://en.wikipedia.org/wiki/Rainbow_attack\" target=\"_blank\">rainbow table</a>\n&gt; attacks.</li>\n</ul>\n"
+          "description_html": "<p>Specifies a file that keeps user names and passwords,\nin the following format:</p>\n\n<pre><code># comment\nname1:password1\nname2:password2:comment\nname3:password3\n</code></pre>\n\n<p>The <em><code>file</code></em> name can contain variables.</p>\n\n<p>The following password types are supported:</p>\n\n<ul>\n<li>encrypted with the <code>crypt()</code> function; can be generated using\nthe “<code>htpasswd</code>” utility from the Apache HTTP Server\ndistribution or the “<code>openssl passwd</code>” command;</li>\n<li>hashed with the Apache variant of the MD5-based password algorithm (apr1);\ncan be generated with the same tools;</li>\n<li>specified by the\n“<code>{</code><em><code>scheme</code></em><code>}</code><em><code>data</code></em>”\nsyntax (1.0.3+) as described in\n<a href=\"https://datatracker.ietf.org/doc/html/rfc2307#section-5.3\" target=\"_blank\">RFC 2307</a>;\ncurrently implemented schemes include <code>PLAIN</code> (an example one,\nshould not be used), <code>SHA</code> (1.3.13) (plain SHA-1\nhashing, should not be used) and <code>SSHA</code> (salted SHA-1 hashing,\nused by some software packages, notably OpenLDAP and Dovecot).\n&gt; Support for <code>SHA</code> scheme was added only to aid\n&gt; in migration from other web servers.\n&gt; It should not be used for new passwords, since unsalted SHA-1 hashing\n&gt; that it employs is vulnerable to\n&gt; <a href=\"http://en.wikipedia.org/wiki/Rainbow_attack\" target=\"_blank\">rainbow table</a>\n&gt; attacks.</li>\n</ul>\n"
         }
       ]
     },
@@ -1031,7 +1031,7 @@
           ],
           "isBlock": false,
           "description_md": "Defines the URI that will be shown for the specified errors.\nA *`uri`* value can contain variables.\n\nExample:\n```\nerror_page 404             /404.html;\nerror_page 500 502 503 504 /50x.html;\n```\n\nThis causes an internal redirect to the specified *`uri`*\nwith the client request method changed to “`GET`”\n(for all methods other than\n“`GET`” and “`HEAD`”).\n\nFurthermore, it is possible to change the response code to another\nusing the “`=`*`response`*” syntax, for example:\n```\nerror_page 404 =200 /empty.gif;\n```\n\nIf an error response is processed by a proxied server\nor a FastCGI/uwsgi/SCGI/gRPC server,\nand the server may return different response codes (e.g., 200, 302, 401\nor 404), it is possible to respond with the code it returns:\n```\nerror_page 404 = /404.php;\n```\n\nIf there is no need to change URI and method during internal redirection\nit is possible to pass error processing into a named location:\n```\nlocation / {\n    error_page 404 = @fallback;\n}\n\nlocation @fallback {\n    proxy_pass http://backend;\n}\n```\n\n> If *`uri`* processing leads to an error,\n> the status code of the last occurred error is returned to the client.\n\nIt is also possible to use URL redirects for error processing:\n```\nerror_page 403      http://example.com/forbidden.html;\nerror_page 404 =301 http://example.com/notfound.html;\n```\nIn this case, by default, the response code 302 is returned to the client.\nIt can only be changed to one of the redirect status\ncodes (301, 302, 303, 307, and 308).\n> The code 307 was not treated as a redirect until versions 1.1.16 and 1.0.13.\n\n\n> The code 308 was not treated as a redirect until version 1.13.0.\n\nThese directives are inherited from the previous configuration level\nif and only if there are no `error_page` directives\ndefined on the current level.",
-          "description_html": "<p>Defines the URI that will be shown for the specified errors.\nA <em><code>uri</code></em> value can contain variables.</p>\n\n<p>Example:</p>\n\n<pre><code>error_page 404             /404.html;\nerror_page 500 502 503 504 /50x.html;\n</code></pre>\n\n<p>This causes an internal redirect to the specified <em><code>uri</code></em>\nwith the client request method changed to “<code>GET</code>”\n(for all methods other than\n“<code>GET</code>” and “<code>HEAD</code>”).</p>\n\n<p>Furthermore, it is possible to change the response code to another\nusing the “<code>=</code>*<code>response</code>*” syntax, for example:</p>\n\n<pre><code>error_page 404 =200 /empty.gif;\n</code></pre>\n\n<p>If an error response is processed by a proxied server\nor a FastCGI/uwsgi/SCGI/gRPC server,\nand the server may return different response codes (e.g., 200, 302, 401\nor 404), it is possible to respond with the code it returns:</p>\n\n<pre><code>error_page 404 = /404.php;\n</code></pre>\n\n<p>If there is no need to change URI and method during internal redirection\nit is possible to pass error processing into a named location:</p>\n\n<pre><code>location / {\n    error_page 404 = @fallback;\n}\n\nlocation @fallback {\n    proxy_pass http://backend;\n}\n</code></pre>\n\n<blockquote>\n<p>If <em><code>uri</code></em> processing leads to an error,\nthe status code of the last occurred error is returned to the client.</p>\n</blockquote>\n\n<p>It is also possible to use URL redirects for error processing:</p>\n\n<pre><code>error_page 403      http://example.com/forbidden.html;\nerror_page 404 =301 http://example.com/notfound.html;\n</code></pre>\n\n<p>In this case, by default, the response code 302 is returned to the client.\nIt can only be changed to one of the redirect status\ncodes (301, 302, 303, 307, and 308).</p>\n\n<blockquote>\n<p>The code 307 was not treated as a redirect until versions 1.1.16 and 1.0.13.</p>\n\n<p>The code 308 was not treated as a redirect until version 1.13.0.</p>\n</blockquote>\n\n<p>These directives are inherited from the previous configuration level\nif and only if there are no <code>error_page</code> directives\ndefined on the current level.</p>\n"
+          "description_html": "<p>Defines the URI that will be shown for the specified errors.\nA <em><code>uri</code></em> value can contain variables.</p>\n\n<p>Example:</p>\n\n<pre><code>error_page 404             /404.html;\nerror_page 500 502 503 504 /50x.html;\n</code></pre>\n\n<p>This causes an internal redirect to the specified <em><code>uri</code></em>\nwith the client request method changed to “<code>GET</code>”\n(for all methods other than\n“<code>GET</code>” and “<code>HEAD</code>”).</p>\n\n<p>Furthermore, it is possible to change the response code to another\nusing the “<code>=</code><em><code>response</code></em>” syntax, for example:</p>\n\n<pre><code>error_page 404 =200 /empty.gif;\n</code></pre>\n\n<p>If an error response is processed by a proxied server\nor a FastCGI/uwsgi/SCGI/gRPC server,\nand the server may return different response codes (e.g., 200, 302, 401\nor 404), it is possible to respond with the code it returns:</p>\n\n<pre><code>error_page 404 = /404.php;\n</code></pre>\n\n<p>If there is no need to change URI and method during internal redirection\nit is possible to pass error processing into a named location:</p>\n\n<pre><code>location / {\n    error_page 404 = @fallback;\n}\n\nlocation @fallback {\n    proxy_pass http://backend;\n}\n</code></pre>\n\n<blockquote>\n<p>If <em><code>uri</code></em> processing leads to an error,\nthe status code of the last occurred error is returned to the client.</p>\n</blockquote>\n\n<p>It is also possible to use URL redirects for error processing:</p>\n\n<pre><code>error_page 403      http://example.com/forbidden.html;\nerror_page 404 =301 http://example.com/notfound.html;\n</code></pre>\n\n<p>In this case, by default, the response code 302 is returned to the client.\nIt can only be changed to one of the redirect status\ncodes (301, 302, 303, 307, and 308).</p>\n\n<blockquote>\n<p>The code 307 was not treated as a redirect until versions 1.1.16 and 1.0.13.</p>\n\n<p>The code 308 was not treated as a redirect until version 1.13.0.</p>\n</blockquote>\n\n<p>These directives are inherited from the previous configuration level\nif and only if there are no <code>error_page</code> directives\ndefined on the current level.</p>\n"
         },
         {
           "name": "etag",
@@ -9191,7 +9191,7 @@
         {
           "name": "$ssl_client_verify",
           "description_md": "returns the result of client certificate verification:\n“`SUCCESS`”, “`FAILED:`*`reason`*”,\nand “`NONE`” if a certificate was not present;\n> Prior to version 1.11.7, the “`FAILED`” result\n> did not contain the *`reason`* string.",
-          "description_html": "<p>returns the result of client certificate verification:\n“<code>SUCCESS</code>”, “<code>FAILED:</code>*<code>reason</code>*”,\nand “<code>NONE</code>” if a certificate was not present;</p>\n\n<blockquote>\n<p>Prior to version 1.11.7, the “<code>FAILED</code>” result\ndid not contain the <em><code>reason</code></em> string.</p>\n</blockquote>\n"
+          "description_html": "<p>returns the result of client certificate verification:\n“<code>SUCCESS</code>”, “<code>FAILED:</code><em><code>reason</code></em>”,\nand “<code>NONE</code>” if a certificate was not present;</p>\n\n<blockquote>\n<p>Prior to version 1.11.7, the “<code>FAILED</code>” result\ndid not contain the <em><code>reason</code></em> string.</p>\n</blockquote>\n"
         },
         {
           "name": "$ssl_curve",
@@ -15696,7 +15696,7 @@
         {
           "name": "$ssl_client_verify",
           "description_md": "returns the result of client certificate verification (1.11.8):\n“`SUCCESS`”, “`FAILED:`*`reason`*”,\nand “`NONE`” if a certificate was not present;",
-          "description_html": "<p>returns the result of client certificate verification (1.11.8):\n“<code>SUCCESS</code>”, “<code>FAILED:</code>*<code>reason</code>*”,\nand “<code>NONE</code>” if a certificate was not present;</p>\n"
+          "description_html": "<p>returns the result of client certificate verification (1.11.8):\n“<code>SUCCESS</code>”, “<code>FAILED:</code><em><code>reason</code></em>”,\nand “<code>NONE</code>” if a certificate was not present;</p>\n"
         },
         {
           "name": "$ssl_curve",