# 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](/grey-matter-documentation/usage/fabric/filters/http.md), which operate at the L7 (Application Layer) level.
2. [Network filters](/grey-matter-documentation/usage/fabric/filters/network.md), 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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://greymatter.gitbook.io/grey-matter-documentation/usage/fabric/filters.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.