Filters are used for preliminary processing of incoming data, and post-processing of outgoing data. Apache implements Filters only in Apache 2.0, higher by a filter chain which alters the traditional request processing phases. Although numerous filters are used internally by Apache to perform functions like chunking and byte-range handling, some other popular filters are :

• mod_include, implements server-side includes.
• mod_ssl, implements SSL encryption (https).
• mod_deflate, implements compression/decompression on the fly.
• mod_ext_filter, runs an external program as a filter.

Apache provides mod_filter module to configure the filter chain dynamically at run time regardless of where the data comes from. For instance, we can set up a proxy to compress all the images, css, javascript, etc.
To be g-zipped prior to sending the response over network, despite the proxy having no information about what the origin server will send.
This is achieved with the help of filter harness which send off to different providers according to the actual contents at run time. We can either insert a filter directly in the chain and configure it to run unconditionally or used as a provider and inserted dynamically.

Filters can be used in one of the two ways :
First is Simple and second is Dynamic (One should be used at a time).

Input filters can only be used in simple way. Although simple way is adequate and enough for output filters where only a static filter chain is required.

Directives relevant to simple way are :

SetInputFilter: It is used to set the filter(s) to process client requests and POST input when they are received by the server. Multiple filters must be separated by semicolons in the order in which they are expected to process the content.

SetOutputFilter: Output Filters which are expected to process the response prior they are sent to the client are set by the SetOutputFilter directive. This is in addition to any filters defined elsewhere, including SetOutputFilter and AddOutputFilterByType directive. This mapping is merged over any already in force, overriding any mappings that already exist for the same extension.

For example, the following configuration will process all files in the /www/data/ directory to be g-zipped.

<Directory /www/data/>
SetOutputFilter DEFLATE
</Directory> 

Multiple filters should be divided/separated using semicolons according to the sequence or order in which they are expected to process the content.

AddInputFilter : Here the file-name extension are mapped to the filters which will process client requests and POST input when they are received by the server. This is an addition to any filters defined some where else, including the SetInputFilter directive.
This relation is merged over any already in force, overriding any mappings that already subsist for the same extension.
Multiple filters must be separated by semicolons in the order in which they are expected to process the content. It is important to note that the extension argument is case-insensitive and can be designated with or without a leading dot. Filenames may have many extensions and the extension argument will be compared against each of them.

AddOutputFilter : Output Filters which are expected to process the response prior they are sent to the client are related to the filename extension. This is in integration to any filters defined elsewhere, including SetOutputFilter and AddOutputFilterByType directive. This relation is merged over any already in force, overriding any relations that already subsist for the same extension.
The filter argument is case-insensitive. Multiple filters must be dissevered by semicolons in the order in which they are expected to process the content.

RemoveInputFilter : It abstracts any input filter sodalities for files with the given extensions. This sanctions .htaccess files in subdirectories to undo any sodalities inherited from parent directories or the server config files.

RemoveOutputFilter : It abstracts any output filter sodalities for files with the given extensions. This sanctions .htaccess files in subdirectories to undo any sodalities inherited from parent directories or the server config files.

The Dynamic Way enables static and flexible, non-static configuration of output filters.

FilterChain : It is to configure the filter chain from declared filters. It takes any number of arguments, each optionally preceded with a single-character control that determines what to do:

Directives relevant to simple way are :

+filter-name 
Add filter-name to the end of the filter chain 
@filter-name 
Insert filter-name at the start of the filter chain 
-filter-name 
Remove filter-name from the filter chain 
=filter-name 
Empty the filter chain and insert filter-name 
! 
Empty the filter chain 
filter-name 
Equivalent to +filter-name 

FilterDeclare : It declares an output filter with a header or an environment variable that will identify runtime configuration. The first argument is a filter-name for use in FilterProvider, FilterChain and FilterProtocol directives. The final (optional) argument is the type of filter, and takes values of ap_filter_type - namely RESOURCE (the default), CONTENT_SET, PROTOCOL, TRANSCODE, CONNECTION or NETWORK.

FilterProvider :It registers a provider for the astute filter. The provider will be called if and only if the match declared here matches the value of the header or an environment variable declared as dispatch.

provider-name must have been registered by loading a module that registers the denomination with ap_register_output_filter.

The dispatch argument is a string with optional req=, resp= or env= prefix causing it to dispatch on (respectively) the request header, replication header, or environment variable denominated. In the absence of a prefix, it defaults to a replication header. A special case is the word handler, which causes mod_filter to dispatch on the content handler.

Reference :

http://httpd.apache.org/docs