Merge branch 'main' into nap-release-plm

Author: ADubhlaoich

.github/workflows/playwright.yml

@@ -9,7 +9,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v4
-    - uses: actions/setup-node@v4
+    - uses: actions/setup-node@v5
       with:
         node-version: lts/*
     - name: Install dependencies

content/ngf/overview/gateway-api-compatibility.md

@@ -174,7 +174,6 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
       - `Accepted/False/NotAllowedByListeners`
       - `Accepted/False/UnsupportedValue`: Custom reason for when the HTTPRoute includes an invalid or unsupported value.
       - `Accepted/False/InvalidListener`: Custom reason for when the HTTPRoute references an invalid listener.
-      - `Accepted/False/GatewayNotProgrammed`: Custom reason for when the Gateway is not Programmed. HTTPRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
       - `Accepted/False/GatewayIgnored`: Custom reason for when the Gateway is ignored by NGINX Gateway Fabric. NGINX Gateway Fabric only supports one Gateway.
       - `ResolvedRefs/True/ResolvedRefs`
       - `ResolvedRefs/False/InvalidKind`
@@ -220,7 +219,6 @@ See the [controller]({{< ref "/ngf/reference/cli-help.md#controller">}}) command
       - `Accepted/False/NotAllowedByListeners`
       - `Accepted/False/UnsupportedValue`: Custom reason for when the GRPCRoute includes an invalid or unsupported value.
       - `Accepted/False/InvalidListener`: Custom reason for when the GRPCRoute references an invalid listener.
-      - `Accepted/False/GatewayNotProgrammed`: Custom reason for when the Gateway is not Programmed. GRPCRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
       - `ResolvedRefs/True/ResolvedRefs`
       - `ResolvedRefs/False/InvalidKind`
       - `ResolvedRefs/False/RefNotPermitted`
@@ -275,7 +273,6 @@ Fields:
       - `Accepted/False/NotAllowedByListeners`
       - `Accepted/False/UnsupportedValue`: Custom reason for when the TLSRoute includes an invalid or unsupported value.
       - `Accepted/False/InvalidListener`: Custom reason for when the TLSRoute references an invalid listener.
-      - `Accepted/False/GatewayNotProgrammed`: Custom reason for when the Gateway is not Programmed. TLSRoute can be valid and configured, but will maintain this status as long as the Gateway is not Programmed.
       - `Accepted/False/HostnameConflict`: Custom reason for when the TLSRoute has a hostname that conflicts with another TLSRoute on the same port.
       - `ResolvedRefs/True/ResolvedRefs`
       - `ResolvedRefs/False/InvalidKind`

content/nginx/admin-guide/basic-functionality/managing-configuration-files.md

@@ -9,11 +9,33 @@ type:
 - how-to
 ---
 
-Similar to other services, NGINX and NGINX Plus use a text‑based configuration file with a precise format. By default the file is named **nginx.conf** and for NGINX Plus is placed in the `/etc/nginx` directory.
+NGINX and NGINX Plus use a text‑based configuration file, by default named **nginx.conf**.
 
-For NGINX Open Source, the location depends on the package system used to install NGINX and the operating system. It is typically one of `/usr/local/nginx/conf`, `/etc/nginx`, or `/usr/local/etc/nginx`.
+NGINX Plus: default location is `/etc/nginx` for Linux or `/usr/local/etc/nginx` for FreeBSD.
+
+NGINX Open Source: location depends on the package system used to install NGINX and the operating system. It is typically one of `/usr/local/nginx/conf`, `/etc/nginx`, or `/usr/local/etc/nginx`.
+
+You can verify the exact configuration file path with the `--conf-path=` parameter in the output of the `nginx -V` command:
+
+```shell
+ nginx -V 2>&1 | awk -F: '/configure arguments/ {print $2}' | xargs -n1
+```
+
+Sample output:
+
+```none
+--prefix=/etc/nginx
+--sbin-path=/usr/sbin/nginx
+--modules-path=/usr/lib64/nginx/modules
+--conf-path=/etc/nginx/nginx.conf          # The path to your config file
+--error-log-path=/var/log/nginx/error.log
+--http-log-path=/var/log/nginx/access.log
+--pid-path=/var/run/nginx.pid
+--...<more parameters>
+```
 
 ## Directives
+
 The configuration file consists of _directives_ and their parameters. Simple (single‑line) directives end with a semicolon ( `;` ). Other directives act as “containers” which group together related directives. Containers are enclosed in curly braces ( `{}` ) and are often referred to as _blocks_. Here are some examples of simple directives.
 
 ```nginx
@@ -22,9 +44,9 @@ error_log        logs/error.log notice;
 worker_processes 1;
 ```
 
-## Feature-Specific Configuration Files
+## Feature-specific configuration files
 
-To make the configuration easier to maintain, we recommend that you split it into a set of feature‑specific files stored in the <span style="white-space: nowrap;">**/etc/nginx/conf.d**</span> directory and use the [include](https://nginx.org/en/docs/ngx_core_module.html#include) directive in the main **nginx.conf** file to reference the contents of the feature‑specific files.
+To make the configuration easier to maintain, it is possible to split it into a set of feature‑specific files stored in the `/etc/nginx/conf.d` directory and use the [include](https://nginx.org/en/docs/ngx_core_module.html#include) directive in the main **nginx.conf** file to reference the contents of the feature‑specific files.
 
 ```nginx
 include conf.d/http;
@@ -43,14 +65,15 @@ A few top‑level directives, referred to as _contexts_, group together the dire
 
 Directives placed outside of these contexts are said to be in the _main_ context.
 
-### Virtual Servers
+### Virtual servers
+
 In each of the traffic‑handling contexts, you include one or more `server` blocks to define _virtual servers_ that control the processing of requests. The directives you can include within a `server` context vary depending on the traffic type.
 
 For HTTP traffic (the `http` context), each [server](https://nginx.org/en/docs/http/ngx_http_core_module.html#server) directive controls the processing of requests for resources at particular domains or IP addresses. One or more [location](https://nginx.org/en/docs/http/ngx_http_core_module.html#location) contexts within a `server` context define how to process specific sets of URIs.
 
 For mail and TCP/UDP traffic (the [mail](https://nginx.org/en/docs/mail/ngx_mail_core_module.html) and [stream](https://nginx.org/en/docs/stream/ngx_stream_core_module.html) contexts) the `server` directives each control the processing of traffic arriving at a particular TCP port or UNIX socket.
 
-### Sample Configuration File with Multiple Contexts
+### Sample configuration file with multiple contexts
 
 The following configuration illustrates the use of contexts.
 
@@ -89,10 +112,10 @@ stream {
 
 ### Inheritance
 
-In general, a _child_ context – a context contained within another context (its _parent_) – inherits the settings of directives included at the parent level. Some directives can appear in multiple contexts, in which case you can override the setting inherited from the parent by including the directive in the child context. For an example, see the [proxy_set_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header) directive.
+In general, a _child_ context – a context contained within another context (its _parent_) – inherits the settings of directives included at the parent level. Some directives can appear in multiple contexts, in which case you can override the setting inherited from the parent by including the directive in the child context. For an example, see the [proxy_set_header](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header) directive.
 
-## Reload Configuration File
+## Reload configuration file
 
 For changes to the configuration file to take effect, it must be reloaded. You can either restart the `nginx` process or send the `reload` signal to upgrade the configuration without interrupting the processing of current requests. For details, see [Control NGINX Processes at Runtime]({{< ref "/nginx/admin-guide/basic-functionality/runtime-control.md" >}}).
 
-With NGINX Plus, you can dynamically reconfigure [load balancing]({{< ref "/nginx/admin-guide/load-balancer/dynamic-configuration-api.md" >}}) across the servers in an upstream group without reloading the configuration. You can also use the NGINX Plus API and key‑value store to dynamically control access, for example [based on client IP address]({{< ref "/nginx/admin-guide/security-controls/denylisting-ip-addresses.md" >}}).
+With NGINX Plus, you can dynamically reconfigure [load balancing]({{< ref "/nginx/admin-guide/load-balancer/dynamic-configuration-api.md" >}}) across the servers in an upstream group without reloading the configuration. You can also use the NGINX Plus API and key‑value store to dynamically control access, for example [based on client IP address]({{< ref "/nginx/admin-guide/security-controls/denylisting-ip-addresses.md" >}}).

content/nginx/admin-guide/installing-nginx/installing-nginx-plus.md

@@ -294,7 +294,7 @@ NGINX Plus can be installed on the following versions of Debian or Ubuntu:
 
 1. {{< include "nginx-plus/install/check-nginx-binary-version.md" >}}
 
-1. {{< include "nginx-plus/install/configure-usage-reporting.md" >}}
+1. Make sure license reporting to F5 licensing endpoint is configured. By default, no configuration is required. However, it becomes necessary when NGINX Plus is installed in a disconnected environment, uses NGINX Instance Manager for usage reporting, or uses a custom path for the license file. Configuration can be done in the [`mgmt {}`](https://nginx.org/en/docs/ngx_mgmt_module.html) block of the NGINX Plus configuration file (`/usr/local/etc/nginx/nginx.conf`). For more information, see [About Subscription Licenses](https://docs.nginx.com/solutions/about-subscription-licenses/).
 
 1. {{< include "nginx-plus/install/install-nginx-agent-for-nim.md" >}}
 
@@ -398,7 +398,7 @@ NGINX Plus can be installed on the following versions of Debian or Ubuntu:
 
 1. {{< include "nginx-plus/install/install-nginx-agent-for-nim.md" >}}
 
-## Install Dynamically Loadable Modules {#install_modules}
+## Install dynamically loadable modules {#install_modules}
 
 NGINX Plus functionality can be extended with dynamically loadable modules. They can be added or updated independently of the core binary, enabling powerful capabilities such as advanced security, traffic shaping, telemetry, embedded scripting, geolocation, and many more.
 
@@ -515,7 +515,7 @@ After installing the module, you will need to:
 - enable it with the [`load_module`](https://nginx.org/en/docs/ngx_core_module.html#load_module) directive
 - configure it according to the module's documentation
 
-### Enabling Dynamic Modules {#enable_dynamic}
+### Enabling dynamic modules {#enable_dynamic}
 
 To enable a dynamic module:
 
@@ -694,7 +694,7 @@ For a community dynamic module to work with NGINX Plus, it must be compiled alo
 
 After installing the module, you need to enable it in the NGINX Plus configuration file. For more information, see [Enabling Dynamic Modules](#enable_dynamic).
 
-## NGINX Plus Unprivileged Installation {#unpriv_install}
+## NGINX Plus unprivileged installation {#unpriv_install}
 
 In some environments, access to the root account is restricted for security reasons. On Linux systems, this limitation prevents the use of package managers to install NGINX Plus without root privileges.
 
@@ -787,7 +787,7 @@ With this script, you can also upgrade an existing unprivileged installation of
 ./ngxunprivinst.sh upgrade [-y] -p <path> <file1.rpm> <file2.rpm>
 ```
 
-## NGINX Plus Offline Installation {#offline_install}
+## NGINX Plus offline installation {#offline_install}
 
 This section explains how to install NGINX Plus and its [dynamic modules]({{< ref "/nginx/admin-guide/dynamic-modules/dynamic-modules.md" >}}) on a server with limited or no Internet access.
 
@@ -982,7 +982,7 @@ To upgrade your NGINX Plus installation to the newest version:
    nginx version: nginx/1.29.0 (nginx-plus-r35)
    ```
 
-## Upgrade NGINX Plus Modules {#upgrade_modules}
+## Upgrade NGINX Plus modules {#upgrade_modules}
 
 The upgrade procedure depends on how the module was supplied and installed.
 
@@ -992,7 +992,7 @@ The upgrade procedure depends on how the module was supplied and installed.
 
 - [Community](#community-dynamic-modules) dynamic modules must be recompiled against the corresponding NGINX Open Source  version. See [Installing NGINX Community Modules](#install_modules_oss).
 
-## Explore Related Topics
+## Explore related topics
 
 ### Install NGINX App Protect