Apache模块mod_filter

智能过滤

在传统过滤模型中，使用AddOutputFilterand系列无条件插入过滤器。然后，每个过滤器都需要确定是否运行，并且服务器管理员几乎没有灵活性来允许动态配置链。

mod_filter相比之下，服务器管理员在配置筛选器链时具有很大的灵活性。实际上，可以基于复杂的布尔表达式插入过滤器。 这概括了所提供的有限的灵活性AddOutputFilterByType。

筛选器声明，提供者和链

图1：传统的过滤器模型

在传统模型中，输出过滤器是一条从内容生成器（处理程序）到客户端的简单链。只要可以正确配置过滤器链，此方法就可以很好地工作，但是当需要根据处理程序的结果动态配置过滤器时，就会出现问题。

图2：该mod_filter模型

mod_filter通过将间接引入过滤器链来工作。我们没有在链中插入过滤器，而是插入了过滤器线束，后者又有条件地分派给过滤器提供者。任何内容过滤器都可以作为提供者mod_filter; 无需更改现有的过滤器模块（尽管可以简化它们）。一个过滤器可以有多个提供程序，但对于单个请求，最多只能运行一个提供程序。

过滤器链包括过滤器线束的任意数量的实例，每个实例可以具有任意数量的提供者。一种特殊情况是具有无条件分派的单个提供程序：这等效于将提供程序过滤器直接插入到链中。

配置链

使用来配置过滤器链分为三个阶段 mod_filter。有关指令的详细信息，请参见下文。

声明过滤器

该FilterDeclare指令声明一个过滤器，为其分配名称和过滤器类型。仅当过滤器不是默认类型AP_FTYPE_RESOURCE时才需要。

注册提供商

该FilterProvider 指令将提供程序注册到过滤器。过滤器可能已经用声明了FilterDeclare；如果不是，FilterProvider将使用默认类型AP_FTYPE_RESOURCE隐式声明它。提供者必须已ap_register_output_filter通过某个模块注册。最后一个参数FilterProvider是表达式：只有且表达式的计算结果为true时，才会选择提供程序来运行请求。该表达式可以求值HTTP请求或响应标头，环境变量或此请求使用的处理程序。与早期版本不同，mod_filter现在支持复杂的表达式，该表达式涉及带有AND / OR逻辑（&& / ||）和方括号的多个条件。表达式语法的详细信息在ap_expr文档中进行了描述。

配置链

上面的指令构建了智能过滤器链的组件，但没有将其配置为运行。该FilterChain指令从声明的智能过滤器构建过滤器链，从而提供了在链的开始或末端插入过滤器，移除过滤器或清除链的灵活性。

筛选和响应状态

mod_filter通常仅对HTTP状态为200（OK）的响应运行筛选器。如果要过滤具有其他响应状态的文档，则可以设置filter-errordocs 环境变量，该变量将对所有响应起作用，而与状态无关。要进一步优化，可以将表达式条件与一起使用FilterProvider。

从Apache HTTP Server 2.2配置升级

该FilterProvider 指令已从httpd 2.2进行了更改：match和 dispatch参数被单个但更通用的表达式替换。通常，您可以使用以下方法将匹配/发送对转换为表达式的两侧：

现在分别从语法％{req：foo}， ％{resp：foo}和％{env：foo}解释Request头，Response头和Environment变量。 还支持变量％{HANDLER}和％{CONTENT_TYPE}。

请注意，该匹配不再支持子字符串匹配。可以将它们替换为正则表达式匹配项。

例子

服务器端包含（SSI）

一个简单的替换案例 AddOutputFilterByType

FilterDeclare SSI
FilterProvider SSI INCLUDES "%{CONTENT_TYPE} =~ m|^text/html|"
FilterChain SSI

服务器端包含（SSI）

与上述相同，但在处理程序上调度（经典SSI行为； .shtml文件得到处理）。

FilterProvider SSI INCLUDES "%{HANDLER} = 'server-parsed'"
FilterChain SSI

用mod_deflate模拟mod_gzip

仅当Accept-Encoding标头中没有“ gzip”时，才插入INFLATE过滤器。该过滤器以ftype CONTENT_SET运行。

FilterDeclare gzip CONTENT_SET
FilterProvider gzip inflate "%{req:Accept-Encoding} !~ /gzip/"
FilterChain gzip

图像下采样

假设我们要对所有Web图像进行降采样，并具有用于GIF，JPEG和PNG的过滤器。

FilterProvider unpack jpeg_unpack "%{CONTENT_TYPE} = 'image/jpeg'"
FilterProvider unpack gif_unpack  "%{CONTENT_TYPE} = 'image/gif'"
FilterProvider unpack png_unpack  "%{CONTENT_TYPE} = 'image/png'"

FilterProvider downsample downsample_filter "%{CONTENT_TYPE} = m|^image/(jpeg|gif|png)|"
FilterProtocol downsample "change=yes"

FilterProvider repack jpeg_pack "%{CONTENT_TYPE} = 'image/jpeg'"
FilterProvider repack gif_pack  "%{CONTENT_TYPE} = 'image/gif'"
FilterProvider repack png_pack  "%{CONTENT_TYPE} = 'image/png'"
<Location "/image-filter">
    FilterChain unpack downsample repack
</Location>

协议处理

从历史上看，每个过滤器负责确保在HTTP响应标头中正确表示它所做的任何更改，并且在进行非法更改时不运行。这给过滤器作者带来了负担，他们需要在每个过滤器中重新实现一些常用功能：

• 许多过滤器将更改内容，使现有的内容标签，校验和，哈希和长度无效。
• 在输入中需要完整无间断响应的过滤器需要确保它们不会从后端获取字节范围。
• 在过滤器中转换输出的过滤器需要确保它们不违反Cache-Control: no-transform来自后端的标头。
• 筛选器可能会使响应不可缓存。

mod_filter目的是为过滤器实现的这些细节提供通用处理，从而降低内容过滤器模块所需的复杂性。这是正在进行的工作；该 FilterProtocol工具的一些此功能对于与Apache 2.0模块向后兼容性。对于httpd 2.1及更高版本， ap_register_output_filter_protocol和 ap_filter_protocolAPI使过滤器模块可以声明自己的行为。

同时，mod_filter不应干扰要处理协议所有方面的过滤器。默认情况下（即在没有任何FilterProtocol指令的情况下），mod_filter 将使标题保持不变。

在编写本文时，此功能尚未经过测试，因为常用的模块旨在与2.0一起使用。使用它的模块应该仔细测试。