# Filters

The Fabric mesh supports a variety of filters for processing requests received by each listener registered to a Grey Matter Proxy. These filters are used to perform various tasks such as rate limiting, authentication, buffering, health checking, header manipulation, etc.

The purpose of this document is to provide a general overview of how a filter is configured throughout the Fabric mesh.

## Types

The Fabric mesh allows for two different types of filters to be configured:

1. [HTTP filters](filters/http), which operate at the L7 (Application Layer) level.
2. [Network filters](filters/network), which operate at L3/L4 (Network/Transport Layers) levels.

## Configuration Objects

Filter configuration throughout the Fabric mesh is managed via updates to two Control API object types:

1. [Listener](https://github.com/DecipherNow/gm-gitbook-sync/tree/e3e37ea47bfd76732e75ca7857554add01dd9fca/usage/objects/listener.md), which receives filter configurations and applies them to an individual listener registered to a Grey Matter Proxy.
2. [Proxy](https://github.com/DecipherNow/gm-gitbook-sync/tree/e3e37ea47bfd76732e75ca7857554add01dd9fca/usage/objects/proxy.md), which receives filter configurations and applies them to all registered listeners in a Grey Matter Proxy. Note that only HTTP filters may be configured in a Proxy object.

## Complications

There are several complications to be aware of when configuring multiple filters of either type for a given listener registered to a Grey Matter Proxy.

### Type Conflicts

All Network filters with the exception of one (the Network RBAC filter) are incompatible with HTTP filters configured for the **same** Listener. This is because Network filters involve recording stats and modifying behavior from raw TCP requests, such as when connecting to a database. If both filter types are configured for the same Listener, downstream traffic will be recorded and modified by both filter types.

To address the need for a service to communicate over both HTTP and TCP, its sidecar should be configured with two Listeners -- one for receiving and directing HTTP traffic, and another for receiving and directing TCP traffic.

### Ordering Dependencies

Filters process incoming requests along two separate **filter chains** (e.g. one for active HTTP filters and another for active Network filters). Each filter processes requests in sequential order, meaning that filters configured further down a filter chain will process requests that already have been modified by a number of filters.

In some cases, enabling a filter further down its filter chain may modify or even nullify the behavior of a filter configured further up the chain. These cases are documented as Known Ordering Dependencies in each respective [HTTP Filters](https://github.com/DecipherNow/gm-gitbook-sync/tree/e3e37ea47bfd76732e75ca7857554add01dd9fca/usage/fabric/filters/http/README.md) and [Network Filters](https://github.com/DecipherNow/gm-gitbook-sync/tree/e3e37ea47bfd76732e75ca7857554add01dd9fca/usage/fabric/filters/network/README.md) document.
