如何在Apache中利用mod_filter构建动态的输出处理流水线-Apache-PHP中文网

mod_filter本身不执行处理，只做条件分发；真正干活的是它调度的底层过滤器（如mod_substitute、mod_deflate），filterdeclare和filterprovider必须成对出现且顺序不可颠倒。

如何在apache中利用mod_filter构建动态的输出处理流水线

mod_filter 本身不执行处理，只做条件分发；真正干活的是它调度的底层过滤器（比如 mod_substitute、mod_deflate、mod_ext_filter），漏掉 provider 或写错匹配表达式，整个流水线就静默失效。

FilterDeclare 和 FilterProvider 必须成对出现，且顺序不能颠倒

FilterDeclare 只是起个名字，没实际逻辑；FilterProvider 才真正绑定一个可执行的过滤器模块和触发条件。两者缺一不可，且必须在 SetOutputFilter 之前完成声明。

FilterDeclare 后面跟的名称（如 json_prettify）要和 FilterProvider 第二个参数一致
FilterProvider 的第三个参数是匹配表达式，支持 Perl 兼容正则：resp=Content-Type $text/json 中的 $ 表示“以…开头”，不是字面美元符
若用环境变量控制，写成 env=ENABLE_JSON_FORMAT，再配合 SetEnvIf 或 RewriteRule [E] 设置该变量
多个条件可用布尔运算符：resp=Content-Type $application/json && env=DEBUG

FilterChain 和 SetOutputFilter 的作用范围必须匹配

FilterChain 是启用某组已声明 provider 的开关，它只影响当前作用域（<directory></directory>、<location></location> 或虚拟主机）。SetOutputFilter 则是把具体 filter 名称挂进输出链——但它不会自动识别未声明的名称。

Apache Superset Dashboard and SQL Exploration Skill

Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

下载

如果在 <virtualhost></virtualhost> 里写了 FilterDeclare mysub 和 FilterProvider mysub ...，但在 <directory></directory> 里只写 SetOutputFilter mysub，会报错 Invalid filter name 'mysub'
常见写法是把 FilterChain 和 SetOutputFilter 放在同一块配置里，或直接在全局声明后用 FilterChain 启用整条链
FilterChain 可叠加：FilterChain mysub json_prettify 表示同时启用两个 provider，执行顺序按列出顺序

用 mod_substitute / mod_ext_filter 当 provider 时，注意输入边界和编码

mod_filter 不修改数据，只是转发；真正解析响应体的是被调用的 provider。这意味着：内容类型是否匹配、字符编码是否一致、输入流是否完整，全由 provider 自己负责。

mod_substitute 默认只处理 text/* 类型，若想处理 application/json，得加 FilterProtocol substitute change=... 并确保 FilterProvider 匹配条件包含该 MIME 类型
mod_ext_filter 要求外部程序从 stdin 读完整响应体、写到 stdout，且不能残留未读输入或阻塞等待——否则 Apache worker 会卡死
所有 provider 都默认按响应头中的 charset 解码输入，如果响应没带 charset（如 Content-Type: application/json），它会退回到 ISO-8859-1，导致中文乱码；显式加 charset=utf-8 到响应头更稳妥
调试时打开 LogLevel filter:trace4，能看到 mod_filter 每次是否命中、调用了哪个 provider

动态流水线最易忽略的其实是响应头生成时机

mod_filter 的匹配依据是响应头（resp=）、请求头（req=）或环境变量（env=），但这些值可能在 handler 执行完才确定——比如 PHP 脚本自己 setHeader，或代理后端返回的原始头。

若用 AddOutputFilterByType，它只看 handler 预设的类型，对 PHP/Proxy 等动态生成的内容经常失准；而 mod_filter 的 resp= 是真正在响应发出前检查，更可靠
但这也意味着：如果你在 Header set 指令里改了 Content-Type，而该指令位置在 FilterProvider 匹配之后，那匹配就失效了——Apache 处理顺序是先跑所有 Header 指令，再走 filter chain
真实环境中建议把关键 header（如 Content-Type、charset）尽量提前固定，或用 RewriteRule [E] + env= 匹配，避开 header 时机问题