diff --git a/reference-lib/package-lock.json b/reference-lib/package-lock.json index 19291a6..6995c81 100644 --- a/reference-lib/package-lock.json +++ b/reference-lib/package-lock.json @@ -1,12 +1,12 @@ { "name": "@nginx/reference-lib", - "version": "1.1.6", + "version": "1.1.7", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "@nginx/reference-lib", - "version": "1.1.6", + "version": "1.1.7", "license": "Apache-2.0", "devDependencies": { "@rollup/plugin-json": "^6.1.0", diff --git a/reference-lib/package.json b/reference-lib/package.json index 07c5545..373753a 100644 --- a/reference-lib/package.json +++ b/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", diff --git a/reference-lib/src/reference.json b/reference-lib/src/reference.json index 8264dfe..527d68b 100644 --- a/reference-lib/src/reference.json +++ b/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": "

Specifies a file that keeps user names and passwords,\nin the following format:

\n\n
# comment\nname1:password1\nname2:password2:comment\nname3:password3\n
\n\n

The file name can contain variables.

\n\n

The following password types are supported:

\n\n\n" + "description_html": "

Specifies a file that keeps user names and passwords,\nin the following format:

\n\n
# comment\nname1:password1\nname2:password2:comment\nname3:password3\n
\n\n

The file name can contain variables.

\n\n

The following password types are supported:

\n\n\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": "

Defines the URI that will be shown for the specified errors.\nA uri value can contain variables.

\n\n

Example:

\n\n
error_page 404             /404.html;\nerror_page 500 502 503 504 /50x.html;\n
\n\n

This 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\n

Furthermore, it is possible to change the response code to another\nusing the “=*response*” syntax, for example:

\n\n
error_page 404 =200 /empty.gif;\n
\n\n

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:

\n\n
error_page 404 = /404.php;\n
\n\n

If there is no need to change URI and method during internal redirection\nit is possible to pass error processing into a named location:

\n\n
location / {\n    error_page 404 = @fallback;\n}\n\nlocation @fallback {\n    proxy_pass http://backend;\n}\n
\n\n
\n

If uri processing leads to an error,\nthe status code of the last occurred error is returned to the client.

\n
\n\n

It is also possible to use URL redirects for error processing:

\n\n
error_page 403      http://example.com/forbidden.html;\nerror_page 404 =301 http://example.com/notfound.html;\n
\n\n

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).

\n\n
\n

The code 307 was not treated as a redirect until versions 1.1.16 and 1.0.13.

\n\n

The code 308 was not treated as a redirect until version 1.13.0.

\n
\n\n

These directives are inherited from the previous configuration level\nif and only if there are no error_page directives\ndefined on the current level.

\n" + "description_html": "

Defines the URI that will be shown for the specified errors.\nA uri value can contain variables.

\n\n

Example:

\n\n
error_page 404             /404.html;\nerror_page 500 502 503 504 /50x.html;\n
\n\n

This 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\n

Furthermore, it is possible to change the response code to another\nusing the “=response” syntax, for example:

\n\n
error_page 404 =200 /empty.gif;\n
\n\n

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:

\n\n
error_page 404 = /404.php;\n
\n\n

If there is no need to change URI and method during internal redirection\nit is possible to pass error processing into a named location:

\n\n
location / {\n    error_page 404 = @fallback;\n}\n\nlocation @fallback {\n    proxy_pass http://backend;\n}\n
\n\n
\n

If uri processing leads to an error,\nthe status code of the last occurred error is returned to the client.

\n
\n\n

It is also possible to use URL redirects for error processing:

\n\n
error_page 403      http://example.com/forbidden.html;\nerror_page 404 =301 http://example.com/notfound.html;\n
\n\n

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).

\n\n
\n

The code 307 was not treated as a redirect until versions 1.1.16 and 1.0.13.

\n\n

The code 308 was not treated as a redirect until version 1.13.0.

\n
\n\n

These directives are inherited from the previous configuration level\nif and only if there are no error_page directives\ndefined on the current level.

\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": "

returns the result of client certificate verification:\n“SUCCESS”, “FAILED:*reason*”,\nand “NONE” if a certificate was not present;

\n\n
\n

Prior to version 1.11.7, the “FAILED” result\ndid not contain the reason string.

\n
\n" + "description_html": "

returns the result of client certificate verification:\n“SUCCESS”, “FAILED:reason”,\nand “NONE” if a certificate was not present;

\n\n
\n

Prior to version 1.11.7, the “FAILED” result\ndid not contain the reason string.

\n
\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": "

returns the result of client certificate verification (1.11.8):\n“SUCCESS”, “FAILED:*reason*”,\nand “NONE” if a certificate was not present;

\n" + "description_html": "

returns the result of client certificate verification (1.11.8):\n“SUCCESS”, “FAILED:reason”,\nand “NONE” if a certificate was not present;

\n" }, { "name": "$ssl_curve",