Merge branch 'main' into main

Author: mjang

content/nap-waf/v5/admin-guide/overview.md

@@ -13,7 +13,7 @@ F5 NGINX App Protect WAF v5, designed for NGINX Open Source and NGINX Plus envir
 
 ### Key Advantages
 
-- Ability to work with NGINX Open Source in addition to NGINX Plus.
+- Ability to work with NGINX Open Source as well as NGINX Plus.
 - Scalable architecture, ideal for both small and large-scale deployments.
 - Seamless integration with existing DevOps and SecOps workflows.
 
@@ -44,7 +44,7 @@ NGINX App Protect WAF v5 supports the following operating systems:
 
 ## Deployment Types
 
-NGINX App Protect WAF v5 supports a range of deployment scenarios to meet various operational needs:
+NGINX App Protect WAF v5 supports a range of use cases to meet various operational needs:
 
 1. [Docker Compose Deployment]({{< ref "/nap-waf/v5/admin-guide/deploy-on-docker.md" >}})
    - Deploys both NGINX and WAF components within containers.
@@ -55,8 +55,8 @@ NGINX App Protect WAF v5 supports a range of deployment scenarios to meet variou
    - Ideal for scalable, cloud-native environments.
 
 3. [NGINX on Host/VM with Containerized WAF]({{< ref "/nap-waf/v5/admin-guide/install.md" >}})
-   - NGINX is operated directly on the host system or a virtual machine, with WAF components deployed in containers.
-   - Perfect for situations where NGINX is already in use on host systems, allowing for the addition of WAF components without disrupting the existing NGINX setup.
+   - NGINX operates on the host system or a virtual machine. WAF components are deployed in containers.
+   - Perfect for situations where NGINX is already in use on host systems. Addition of WAF components will not disrupt the existing NGINX setup.
 
 ## NGINX App Protect WAF Compiler
 
@@ -70,41 +70,41 @@ For signature updates, read the [Update App Protect Signatures]({{< ref "/nap-wa
 
 ## Transitioning from NGINX App Protect WAF v4 to v5
 
-Upgrading directly from v4 to v5 is not supported due to architectural changes in NGINX App Protect WAF v5.
+Upgrading from v4 to v5 is not supported due to architectural changes in NGINX App Protect WAF v5.
 
 {{< note >}}
-We recommend that you deploy the NGINX App Protect WAF v5 in a staging environment.  Only after you compile policies with WAF compiler and test the enforcement should you transfer the traffic from the v4 to v5. This keeps the v4 deployment for backup.
+We recommend that you deploy the NGINX App Protect WAF v5 in a staging environment.  Compile policies with WAF compiler and test the enforcement before you transfer the traffic from the v4 to v5. This keeps the v4 deployment for backup.
 {{< /note >}}
 
-1. Back up your NGINX App Protect WAF configuration files, such as NGINX configurations, JSON policies, logging profiles, user-defined signatures, and global settings.
+1. Back up your NGINX App Protect WAF configuration files. These include NGINX configurations, JSON policies, logging profiles, user-defined signatures, and global settings.
 
-1. Install NGINX App Protect WAF 5 (using either nginx OSS or nginx-plus based on the need of customer's application).
+2. Install NGINX App Protect WAF 5. Use either nginx OSS or nginx-plus based on the need of customer's application.
    - [Installing NGINX App Protect WAF]({{<ref "/nap-waf/v5/admin-guide/install.md">}})
    - [Deploying NGINX App Protect WAF on Docker]({{<ref "/nap-waf/v5/admin-guide/deploy-on-docker.md">}})
    - [Deploying NGINX App Protect WAF on Kubernetes]({{<ref "/nap-waf/v5/admin-guide/deploy-with-helm.md">}})
 
-1. Compile your `.json` policies and logging profiles to `.tgz` bundles using [compiler-image]({{<ref "/nap-waf/v5/admin-guide/compiler.md">}}) because NGINX App Protect WAF v5 supports policies and logging profiles in a compiled bundle format only.
+3. Compile your `.json` policies and logging profiles to `.tgz` bundles using [compiler-image]({{<ref "/nap-waf/v5/admin-guide/compiler.md">}}). NGINX App Protect WAF v5 supports policies and logging profiles in a compiled bundle format only.
 
    {{< note >}}
-   If you were previously using a default [logging profile]({{<ref "/nap-waf/v5/admin-guide/deploy-on-docker.md#using-policy-and-logging-profile-bundles">}}) JSON like `/opt/app_protect/share/defaults/log_all.json`, you can replace it with the default constant such as `log_all`, and then you will not need to explicitly compile the logging profile into a bundle.
+   If you were previously using a default [logging profile]({{<ref "/nap-waf/v5/admin-guide/deploy-on-docker.md#using-policy-and-logging-profile-bundles">}}) JSON like `/opt/app_protect/share/defaults/log_all.json`, you can replace it with the default constant such as `log_all`, and then you will not need to compile the logging profile into a bundle.
 
    ```nginx
    app_protect_security_log log_all /log_volume/security.log;
    ```
 
    {{< /note >}}
 
-1. Replace the `.json` references in nginx.conf with the above created `.tgz` [bundles]({{<ref "/nap-waf/v5/admin-guide/install.md#using-policy-and-logging-profile-bundles">}}).
+4. Replace the `.json` references in nginx.conf with the above created `.tgz` [bundles]({{<ref "/nap-waf/v5/admin-guide/install.md#using-policy-and-logging-profile-bundles">}}).
 
-1. Make sure that `.tgz` bundles references are accessible to the `waf-config-mgr` container.
+5. Make sure that `.tgz` bundles references are accessible to the `waf-config-mgr` container.
 
-1. Restart the deployment if it has already been initiated. Additionally, restart NGINX if utilizing the VM + containers deployment type.  After the migrations, check that the NGINX process is running in the NGINX error log and there are no issues.
+6. Restart the deployment if it has already initiated. Additionally, restart NGINX if utilizing the VM + containers deployment type.  After the migrations, check that the NGINX process is running in the NGINX error log and there are no issues.
 
 
 ---
 
 ## Troubleshooting and FAQs
 
-See common deployment challenges and solutions to ensure a smooth setup process in the [Troubleshooting Guide]({{< ref "/nap-waf/v5/troubleshooting-guide/troubleshooting.md#nginx-app-protect-5" >}}).
+Review the [Troubleshooting Guide]({{< ref "/nap-waf/v5/troubleshooting-guide/troubleshooting.md#nginx-app-protect-5" >}}) for common deployment challenges and solutions to ensure a smooth setup process.
 
 Docker images for NGINX App Protect WAF v5 are built using Ubuntu 22.04 (Jammy) binaries.

content/ngf/overview/resource-validation.md

@@ -62,8 +62,8 @@ More information on CEL in Kubernetes can be found [here](https://kubernetes.io/
 This step catches the following cases of invalid values:
 
 - Valid values from the Gateway API perspective but not supported by NGINX Gateway Fabric yet. For example, a feature in an HTTPRoute routing rule. For the list of supported features see [Gateway API Compatibility]({{< relref "./gateway-api-compatibility.md" >}}) doc.
-- Valid values from the Gateway API perspective, but invalid for NGINX, because NGINX has stricter validation requirements for certain fields. These values will cause NGINX to fail to reload or operate erroneously.
-- Invalid values (both from the Gateway API and NGINX perspectives) that were not rejected because Step 1 was bypassed. Similar to the previous case, these values will cause NGINX to fail to reload or operate erroneously.
+- Valid values from the Gateway API perspective, but invalid for NGINX. NGINX has stricter validation requirements for certain fields. These values will cause NGINX to fail to reload or operate erroneously.
+- Invalid values (both from the Gateway API and NGINX perspectives) that were not rejected because Step 1 was bypassed. These values will cause NGINX to fail to reload or operate incorrectly.
 - Malicious values that inject unrestricted NGINX config into the NGINX configuration (similar to an SQL injection attack).
 
 Below is an example of how NGINX Gateway Fabric rejects an invalid resource. The validation error is reported via the status:

content/nginx/admin-guide/content-cache/content-caching.md

@@ -17,7 +17,7 @@ When caching is enabled, F5 NGINX Plus saves responses in a disk cache and uses
 To learn more about NGINX Plus’s caching capabilities, watch the [Content Caching with NGINX](https://nginx.com/resources/webinars/content-caching-nginx-plus/) webinar on demand and get an in‑depth review of features such as dynamic [content caching](https://nginx.com/products/nginx/caching/), cache purging, and delayed caching.
 
 <span id="enable"></span>
-## Enabling the Caching of Responses
+## Enable the Caching of Responses
 
 To enable caching, include the [`proxy_cache_path`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path) directive in the top‑level `http {}` context. The mandatory first parameter is the local filesystem path for cached content, and the mandatory `keys_zone` parameter defines the name and size of the shared memory zone that is used to store metadata about cached items:
 
@@ -65,7 +65,7 @@ proxy_cache_path /data/nginx/cache keys_zone=mycache:10m loader_threshold=300 lo
 ```
 
 <span id="select"></span>
-## Specifying Which Requests to Cache
+## Specify Which Requests to Cache
 
 By default, NGINX Plus caches all responses to requests made with the HTTP `GET` and `HEAD` methods the first time such responses are received from a proxied server. As the key (identifier) for a request, NGINX Plus uses the request string. If a request has the same key as a cached response, NGINX Plus sends the cached response to the client. You can include various directives in the `http {}`, `server {}`, or `location {}` context to control which responses are cached.
 
@@ -88,7 +88,7 @@ proxy_cache_methods GET HEAD POST;
 ```
 
 <span id="bypass"></span>
-## Limiting or Disabling Caching
+## Limit or Disable Caching
 
 By default, responses remain in the cache indefinitely. They are removed only when the cache exceeds the maximum configured size, and then in order by length of time since they were last requested. You can set how long cached responses are considered valid, or even whether they are used at all, by including directives in the `http {}`, `server {}`, or `location {}` context:
 
@@ -118,12 +118,12 @@ proxy_no_cache $http_pragma $http_authorization;
 ```
 
 <span id="purge"></span>
-## Purging Content From The Cache
+## Purge Content From The Cache
 
 NGINX makes it possible to remove outdated cached files from the cache. This is necessary for removing outdated cached content to prevent serving old and new versions of web pages at the same time. The cache is purged upon receiving a special “purge” request that contains either a custom HTTP header, or the HTTP `PURGE` method.
 
 <span id="purge_configure"></span>
-### Configuring Cache Purge
+### Configure Cache Purge
 
 Let’s set up a configuration that identifies requests that use the HTTP `PURGE` method and deletes matching URLs.
 
@@ -156,7 +156,7 @@ Let’s set up a configuration that identifies requests that use the HTTP `PURGE
     ```
 
 <span id="purge_request"></span>
-### Sending the Purge Command
+### Send the Purge Command
 
 When the `proxy_cache_purge` directive is configured, you need to send a special cache‑purge request to purge the cache. You can issue purge requests using a range of tools, including the `curl` command as in this example:
 
@@ -171,7 +171,7 @@ Connection: keep-alive
 In the example, the resources that have a common URL part (specified by the asterisk wildcard) are purged. However, such cache entries are not removed completely from the cache: they remain on disk until they are deleted for either inactivity (as determined by the `inactive` parameter to the [`proxy_cache_path`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path) directive) or by the cache purger (enabled with the [`purger`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#purger) parameter to `proxy_cache_path`), or a client attempts to access them.
 
 <span id="purge_secure"></span>
-### Restricting Access to the Purge Command
+### Restrict Access to the Purge Command
 
 We recommend that you limit the number of IP addresses that are allowed to send a cache‑purge request:
 
@@ -191,7 +191,7 @@ map $request_method $purge_method {
 In this example, NGINX checks if the `PURGE` method is used in a request, and, if so, analyzes the client IP address. If the IP address is whitelisted, then the `$purge_method` is set to `$purge_allowed`: `1` permits purging, and `0` denies it.
 
 <span id="purge_remove"></span>
-### Completely Removing Files from the Cache
+### Completely Remove Files from the Cache
 
 To completely remove cache files that match an asterisk, activate a special `cache purger` process that permanently iterates through all cache entries and deletes the entries that match the wildcard key. Include the [`purger`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#purger) parameter to the [`proxy_cache_path`](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_path) directive in the `http {}` context:
 

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

@@ -24,7 +24,7 @@ type:
 
 
 <span id="nginx_plus_official_images"></span>
-## Using official NGINX Plus Docker images
+## Use official NGINX Plus Docker images
 
 Since NGINX Plus NGINX Plus [Release 31]({{< ref "nginx/releases.md#r31" >}}) you can get an NGINX Plus image from the official NGINX Plus Docker registry and upload it to your private registry.
 
@@ -66,7 +66,7 @@ The NGINX Plus registry contains images for the two most recent versions of NGIN
 
 The image may contain a particular version of NGINX Plus or contain a bundle of NGINX Plus and NGINX Agent, and can be targeted for a specific architecture.
 
-### Listing all tags
+### List all tags
 
 For a complete tag list for NGINX Plus bundled with NGINX Agent images, use the command:
 
@@ -90,7 +90,7 @@ where:
 
 
 
-### Downloading the JSON Web Token or NGINX Plus certificate and key {#myf5-download}
+### Download the JSON Web Token or NGINX Plus certificate and key {#myf5-download}
 
 Before you get a container image, you should provide the JSON Web Token file or SSL certificate and private key files provided with your NGINX Plus subscription. These files grant access to the package repository from which the script will download the NGINX Plus package:
 
@@ -109,7 +109,7 @@ Before you get a container image, you should provide the JSON Web Token file or
 
 {{% /tabs %}}
 
-### Set up Docker for NGINX Plus Container Registry
+### Set up Docker for NGINX Plus container registry
 
 Set up Docker to communicate with the NGINX Container Registry located at `private-registry.nginx.com`.
 
@@ -144,7 +144,7 @@ docker login private-registry.nginx.com
 
 {{% /tabs %}}
 
-### Pulling the image
+### Pull the image
 
 Next, pull the image you need from `private-registry.nginx.com`.
 
@@ -183,7 +183,7 @@ docker pull private-registry.nginx.com/nginx-plus/modules:<version-tag>
 
 {{< include "security/jwt-password-note.md" >}}
 
-### Pushing the image to your private registry
+### Push the image to your private registry
 
 After pulling the image, tag it and upload it to your private registry.
 
@@ -205,7 +205,7 @@ docker tag private-registry.nginx.com/nginx-plus/base:<version-tag> <my-docker-r
 docker push <my-docker-registry>/nginx-plus/base:<version-tag>
 ```
 
-### Running the NGINX Plus container
+### Run the NGINX Plus container
 
 {{< note >}} Starting from [NGINX Plus Release 33]({{< ref "nginx/releases.md#r33" >}}), the JWT file is required for each NGINX Plus instance. For more information, see [About Subscription Licenses]({{< ref "/solutions/about-subscription-licenses.md">}}). {{< /note >}}
 
@@ -390,7 +390,7 @@ Any change made to the files in the local directories `/var/www and /var/nginx/c
 
 
 <span id="manage_copy"></span>
-### Copying Content and Configuration Files from the Docker Host
+### Copy content and configuration files from the Docker host
 
 Docker can copy the content and configuration files from a local directory on the Docker host during container creation. Once a container is created, the files are maintained by creating a new container when files change or by modifying the files in the container.
 
@@ -421,7 +421,7 @@ To make changes to the files in the container, use a helper container as describ
 
 
 <span id="manage_container"></span>
-### Maintaining Content and Configuration Files in the Container
+### Maintain content and configuration files in the container
 
 As SSH cannot be used to access the NGINX container, to edit the content or configuration files directly you need to create a helper container that has shell access. For the helper container to have access to the files, create a new image that has the proper Docker data volumes defined for the image:
 
@@ -476,12 +476,12 @@ To exit the shell and terminate the container, run the `exit` command.
 
 
 <span id="log"></span>
-## Managing Logging
+## Manage logging
 
 You can use default logging or customize logging.
 
 <span id="log_default"></span>
-### Using Default Logging
+### Use default logging
 
 By default, the NGINX image is configured to send NGINX [access log](https://nginx.org/en/docs/http/ngx_http_log_module.html#access_log) and [error log](https://nginx.org/en/docs/ngx_core_module.html#error_log) to the Docker log collector. This is done by linking them to `stdout` and `stderr`: all messages from both logs are then written to the file `/var/lib/docker/containers/container-ID/container-ID-json.log` on the Docker host. The container‑ID is the long‑form ID returned when you [create a container](#docker_oss_image). To display the long form ID, run the command:
 
@@ -507,7 +507,7 @@ To include only access log messages in the output, include only `stdout=1`. To l
 
 
 <span id="log_custom"></span>
-### Using Customized Logging
+### Use customized logging
 
 If you want to configure logging differently for certain configuration blocks (such as `server {}` and `location {}`), define a Docker volume for the directory in which to store the log files in the container, create a helper container to access the log files, and use any logging tools. To implement this, create a new image that contains the volume or volumes for the logging files.
 
@@ -524,7 +524,7 @@ Then you can [create an image](#docker_plus_image) and use it to create an NGINX
 
 
 <span id="control"></span>
-## Controlling NGINX
+## Control NGINX
 
 Since there is no direct access to the command line of the NGINX container, NGINX commands cannot be sent to a container directly. Instead, [signals](https://nginx.org/en/docs/control.html) can be sent to a container via Docker `kill` command.