Add request mirroring policies

en/docs/create-api/create-and-attach-api-policies/header-modifier-filters/overview.md

@@ -0,0 +1,14 @@
+# Header Modification
+
+The header modification functionality allows the addition, modification, and removal of headers in both requests and responses. This capability is useful for enhancing control and flexibility in API interactions, ensuring that specific requirements for incoming requests and outgoing responses are consistently met. This functionality is configured using the HTTPRoute filters `RequestHeaderModifier` and `ResponseHeaderModifier` filters, which specify how headers should be manipulated at various stages of the request and response lifecycle.
+
+Header modification can also be achieved using interceptors, as detailed in [this section](../interceptors/interceptors-overview.md). In a scenario where both interceptors and header modification policies are used, **the header modification filters will be applied after the interceptor.** For example. consider the following scenario.
+
+Assume the GET /employee route is configured with the following.
+
+1. An interceptor policy to add a header with the name "Interceptor-Header" and the value "Interceptor-Value".
+2. A header modification policy to add a header with the name "Modifier-Header" and value "Modifier-Value".
+
+In this scenario, the interceptor headers will be added **first**, followed by the headers from the header modification policy. 
+
+You can also remove headers added by an interceptor using a header modification policy. Additionally, if you have configured a [mirror policy](../mirror-request-filters/overview.md) for this route, the modified headers will be sent in the mirrored request as well.

en/docs/create-api/create-and-attach-api-policies/mirror-request-filters/mirror-request-via-crs.md

@@ -0,0 +1,97 @@
+# Mirroring Requests via CRs
+
+This functionality enables request mirroring, where a request can be duplicated and sent to multiple backends for testing and monitoring. This guide explains how to enable request mirroring via Kubernetes CRs.
+
+### Step 1 - Get the CRs for the relevant API configuration
+
+Here, you can follow the steps in [Develop and Deploy a REST API via CRs](../../create-and-deploy-apis/rest/create-rest-api-using-crs.md) documentation and create the CRs to deploy an API from scratch. 
+
+Alternatively, you can generate the CRs for a given apk-conf file using the steps as detailed in [this section]({{base_path}}/en/latest/api-management-overview/tools-for-api-development/#option-2-generate-k8s-custom-resources-using-config-generator-tool-and-deploy-the-api-using-kubernetes-client)
+
+### Step 2 - Add the header modification filters to the HTTPRoute CR
+
+Header modification can be done using an HTTPRoute filter as follows.
+
+First, create the relevant Backend CR to mirror the request to. A sample Backend CR is provided below.
+
+```
+apiVersion: "dp.wso2.com/v1alpha1"
+kind: "Backend"
+metadata:
+ name: "mirror-backend"
+spec:
+ services:
+ - host: "webhook.site"
+ port: 443
+ basePath: "/30cd1472-d4ac-4440-ab8d-66fc0a789c7b"
+ protocol: "https"
+```
+
+Then you can refer to this CR in your HTTPRoute CR as follows.
+
+```
+filters:
+ - type: "RequestMirror"
+ requestMirror:
+ backendRef:
+ group: "dp.wso2.com"
+ kind: "Backend"
+ name: "mirror-backend"
+```
+
+The complete sample HTTPRoute is as follows.
+
+```
+apiVersion: "gateway.networking.k8s.io/v1beta1"
+kind: "HTTPRoute"
+metadata:
+ name: "production-httproute"
+spec:
+ hostnames:
+ - "default.gw.wso2.com"
+ rules:
+ - matches:
+ - path:
+ type: "RegularExpression"
+ value: "/employee"
+ method: "GET"
+ filters:
+ - type: "RequestMirror"
+ requestMirror:
+ backendRef:
+ group: "dp.wso2.com"
+ kind: "Backend"
+ name: "mirror-backend"
+ parentRefs:
+ - group: "gateway.networking.k8s.io"
+ kind: "Gateway"
+ name: "wso2-apk-default"
+ sectionName: "httpslistener"
+```
+
+This policy mirrors the request to the production/sandbox endpoint, as well as the relevant mirror URL.
+
+### Step 3 - Deploy the API in APK
+
+You can deploy the API using the following command. Replace <namespace> with the correct namespace.
+```
+kubectl apply -f . -n <namespace>
+```
+
+### Step 4 - Generate an access token
+
+Follow the [Generate Access Token](../../../develop-and-deploy-api/security/generate-access-token.md) documentation to generate an access token.
+
+### Step 5 - Invoke the API
+
+You can invoke the API using the following command.
+
+```
+curl --location 'https://default.gw.wso2.com:9095/employee/1.0/employee' \
+--header 'Host: default.gw.wso2.com' \
+--header 'Authorization: Bearer <accessToken>
+```
+
+Once you have invoked the above, you can view the duplicated requests in the webhook.site page as follows.
+
+[![Request Mirroring](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png)](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png)

en/docs/create-api/create-and-attach-api-policies/mirror-request-filters/mirror-request-via-rest-api.md

@@ -0,0 +1,90 @@
+# Mirroring Requests via APK Conf
+
+This functionality enables request mirroring, where a request can be duplicated and sent to multiple backends for testing and monitoring. This guide explains how to enable request mirroring via the APK-Conf file.
+
+### Step 1 - Get the API configuration
+
+Here, you can follow the steps in [Create an API](../../../get-started/quick-start-guide.md) documentation and save this content into a file named `EmployeeService.apk-conf`. You can use this apk-conf file for the rest of this guide.
+
+### Step 2 - Add the request mirroring policy to the apk-conf file
+
+A sample request mirror configuration is given below.
+For this guide, it's best to use a webhook.site URL for both the production and request mirroring endpoints to view the duplicate requests. Replace the `WEBHOOK_URL` with a relevant webhook url from the site `https://webhook.site`. Ensure that you keep this webpage open to view the incoming requests.
+
+```
+ - target: "/employee"
+ verb: "GET"
+ secured: false
+ scopes: []
+ operationPolicies:
+ request:
+ - policyName: RequestMirror
+ policyVersion: v1
+ parameters:
+ urls:
+ - `WEBHOOK_URL`
+```
+
+This policy mirrors the request to the production/sandbox endpoint, as well as the relevant mirror URL.
+
+The complete apk-conf file with this configuration is given below.
+
+```
+id: "header-modifier-api"
+name: "EmployeeServiceAPI"
+basePath: "/employee"
+version: "1.0"
+type: "REST"
+defaultVersion: false
+endpointConfigurations:
+ production:
+ endpoint: `WEBHOOK_URL`
+operations:
+- target: "/employee"
+ verb: "GET"
+ secured: false
+ scopes: []
+ operationPolicies:
+ request:
+ - policyName: RequestMirror
+ policyVersion: v1
+ parameters:
+ urls:
+ - `WEBHOOK_URL`
+- target: "/employee"
+ verb: "POST"
+ secured: true
+ scopes: []
+- target: "/employee/{employeeId}"
+ verb: "PUT"
+ secured: true
+ scopes: []
+- target: "/employee/{employeeId}"
+ verb: "DELETE"
+ secured: true
+ scopes: []
+```
+
+### Step 3 - Deploy the API in APK
+
+Refer to the [Deploy the API in APK](../../../get-started/quick-start-guide.md#deploy-the-api-in-apk) to deploy the API using APK configuration.
+
+### Step 4 - Generate an access token
+
+Follow the [Generate Access Token](../../../develop-and-deploy-api/security/generate-access-token.md) documentation to generate an access token.
+
+### Step 5 - Invoke the API
+
+You can invoke the API using the following command.
+
+```
+curl --location 'https://default.gw.wso2.com:9095/employee/1.0/employee' \
+--header 'Host: default.gw.wso2.com' \
+--header 'Authorization: Bearer <accessToken>
+```
+
+Once you have invoked the above, you can view the duplicated requests in the webhook.site page as follows.
+
+[![Request Mirroring](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png)](../../../assets/img/api-management/api-policies/webhook-site-request-mirroring.png)
+
+

en/docs/create-api/create-and-attach-api-policies/mirror-request-filters/overview.md

@@ -0,0 +1,10 @@
+# Request Mirroring
+
+Request mirroring allows traffic to be duplicated and sent to additional backends for testing and monitoring purposes. This feature is particularly useful for scenarios where you want to test changes or monitor the behavior of your application under different conditions without affecting the primary production or sandbox environment. The Request Mirror filter can mirror requests to different backends apart from the primary backend defined in the production or sandbox endpoints.
+
+The current implementation operates in a “fire and forget” manner, and only the response from the primary endpoint will be returned. This allows for the assessment of changes and performance in a real-world environment without impacting the actual user experience. This method ensures that the production environment remains stable while providing insights into how updates or modifications would perform under actual load conditions.
+
+Request mirroring can be done in one of two ways.
+
+1. Via REST API (using the APK-Conf file).
+2. Via CRs.

en/mkdocs.yml

@@ -124,6 +124,7 @@ nav:
  - Via REST API: create-api/create-and-attach-api-policies/cors/enable-cors-via-rest-api.md
  - Via CRs: create-api/create-and-attach-api-policies/cors/enable-cors-via-crs.md
  - Header Modification:
+ - Overview: create-api/create-and-attach-api-policies/header-modifier-filters/overview.md
  - Via REST API: create-api/create-and-attach-api-policies/header-modifier-filters/header-modifier-via-rest-api.md
  - Via CRs: create-api/create-and-attach-api-policies/header-modifier-filters/header-modifier-via-crs.md
  - Request Mirroring: