Project: Gloo (Orchestration & Management / API Gateway)
File: traffic_filter.md

title: Traffic processing weight: 25 With Gloo Edge, you can configure the gateway listener along with custom Envoy filters to process the traffic that enters into and out of your environment. By mutating requests to and responses from your upstream services, you can decouple and scale your services more dynamically. For an overview of Gloo Edge gateway, virtual service, and upstream configurations, see . Review the following types of request processing that you can do, and see the linked guides for more configuration details. Transformations can be applied to VirtualHosts, Routes, and WeightedDestinations parts of a Gloo Edge Virtual Service custom resource. Example transformations include the following. coming from an Upstream service. of a request. for your access logs. For example steps, see the . Not all requests should be sent to an Upstream destination. Review the following situations in which you might use a direct response or redirect. You want to redirect the response to another website () or to another Virtual Service in Gloo Edge. You want to redirect clients that request the HTTP version of a service to the . You want to return a from the Virtual Service to the client's request, such as a `404 not found` error message. Faults are a way to test the resilience of your services by injecting faults (errors and delays) into a percentage of your requests. Gloo Edge can do this automatically by . Gloo Edge will attempt to send requests to the proper Upstream, but there may be times when that Upstream service is unable to handle additional requests. The `timeout` and `retry` portions of the `options` section for a route define how long to wait for a response from the Upstream service and what type of retry strategy should be used. ```yaml options: timeout: '20s' retries: retryOn: 'connect-failure' numRetries: 3 perTryTimeout: '5s' ``` More information about configuring the and can be found in their respective guides. You can control the rollout of changes using canary releases or blue-green deployments with Upstream Groups. The downside to using either feature is that your are working with live traffic. Real clients are consuming the new version of your service, with potentially negative consequences. An alternative is to shadow the client traffic to your new release, while still processing the original request normally. makes a copy of an incoming request and sends it out-of-band to the new version of your service, without altering the original request. In general, options that you set in a parent object are inherited by a child object. Then, the child has both its own options and those of its parent appended. If the option in the child and parent conflict, the child option takes precedence and overwrites the parent option. You can change this behavior by setting the `inheritTransformation` option to `false` in the children

Examples of parent and child objects: VirtualHost parent object options append to children objects like Routes and WeightedDestinations Route parent object options append to children objects like WeightedDestinations For examples of inherited options, see the following guides: The order that Envoy applies filters to traffic impacts how you configure your Gloo Edge resources. Review the following video and diagrams to understand the filter flow in Gloo Edge. For more information on configuring traffic filters, see the . <iframe width="560" height="315" src="https://www.youtube.com/embed/pN12nxpJ_EE" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe> Review the following diagram of how Gloo Edge filters traffic, depending on what you configure. Notes on the filter policies that you can configure: The filters are applied in the order that is shown in the diagram. For example, if you apply both CORS and DLP security filters, a request is processed for CORS first, and then DLP. You cannot change the order. If you add a policy at both the `VirtualService` and `Route` levels, the `Route` policy takes precedence. <figure><img src="{{% versionedlinkpath fromRoot="/img/traffic-filter-flow.svg" %}}"> <figcaption style="text-align:center;font-style:italic">Figure: Filter flow.</figcaption></figure> External auth: When you enable the external authorization and authentication service in Gloo Edge Enterprise, you can secure access to your apps with authentication tools like OIDC, API keys, OAuth2, or OPA. External auth is used to organize the flow in this diagram so that you can quickly see how traffic can be manipulated before or after requiring the client to log in. For more information, see . Before or after external auth: You can configure several traffic filters either before, after, or both before and after a client request is authorized. JWT*: You can verify a JSON web token (JWT) signature, check the claims, and add them to new headers. To set JWT before and/or after external auth, use the `JwtStaged` setting. For more information, see . Transformation*: Apply transformation templates to the header or body request. If the body is a JSON payload, you can also extract values from it. The `clearRouteCache` setting clears the route that was initially selected by the HTTP connection manager, with the final route selected when the request reaches the Router filter. To set transformations before and/or after external auth, use the `stagedTransformation` setting. For more information, see . Rate limiting*: Rate limiting can take place before or after external auth. You can use the `SetStyle` API to build complex rules for rate limiting. For more information, see . Filters only before external auth: Review the information about other filters that you can apply only before external auth. Fault*: See the . CORS*: See the . DLP*: See the . WAF*: See the . Sanitize*: See the . Filters only after external auth: Review the information about other filters that you can apply only after external auth. RBAC*: Note that the RBAC filter requires the `JwtStaged` filter. See the . gRPC-web*: See the . CSRF*: See the . Router: With the router filter, you can configure many different settings before the request reaches your upstream service, such as the following. For more information, see the . Add or remove request headers Add or remove response headers Set upstream timeouts Rewrite prefixes Automatically rewrite hosts Rewrite with regular expressions (regex) Retry policies Detect outliers Shadow or mirror requests