# 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](https://greymatter.gitbook.io/grey-matter-documentation/1.3/reference/api/fabric-api/filters/http), which operate at the L7 (Application Layer) level.
2. [Network filters](https://greymatter.gitbook.io/grey-matter-documentation/1.3/reference/api/fabric-api/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://greymatter.gitbook.io/grey-matter-documentation/1.3/reference/api/fabric-api/listener), which receives filter configurations and applies them to an individual listener registered to a Grey Matter Proxy.
2. [Proxy](https://greymatter.gitbook.io/grey-matter-documentation/1.3/reference/api/fabric-api/proxy), 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://greymatter.gitbook.io/grey-matter-documentation/1.3/reference/api/fabric-api/filters/http) and [Network Filters](https://greymatter.gitbook.io/grey-matter-documentation/1.3/reference/api/fabric-api/filters/network) document.