WSO2 EI缓存中介：缓存控制头验证、配置及失效问题排查

我来帮你梳理下WSO2 EI缓存中介中缓存控制头的两个核心问题，结合你遇到的配置未生效情况详细说明：

一、启用与配置缓存控制头（解决你的配置失效问题） #

首先得明确<cacheMediator enableCacheControl="true"/>的作用：当这个参数设为true时，缓存中介会自动根据缓存的超时时间生成并覆盖响应的Cache-Control头，这就是你手动添加的<header name="Cache-Control" scope="transport" value="no-cache"/>没生效的原因——缓存中介在处理响应时，会把你自定义的头替换成它自动生成的（比如max-age=xxx，其中xxx是你设置的timeout参数值，单位秒）。

针对你的场景，有两种解决方案： #

1. 完全自定义Cache-Control头
   如果想使用自己设置的Cache-Control指令，把enableCacheControl设为false，这样缓存中介就不会自动生成头，你手动添加的transport级头就会正常传递到客户端：

   <cacheMediator enableCacheControl="false" timeout="3600"/>
   <header name="Cache-Control" scope="transport" value="no-cache, no-store, must-revalidate"/>
   

   注意：头中介的位置要放在缓存中介之后，避免被其他处理逻辑覆盖。

2. 让缓存中介自动生成，补充其他指令
   如果你想保留缓存中介自动生成的max-age，同时添加其他Cache-Control指令，可以在缓存中介之后添加头中介，合并指令：

   <cacheMediator enableCacheControl="true" timeout="3600"/>
   <header name="Cache-Control" scope="transport" value="$trp:Cache-Control, public"/>
   

   这样最终的响应头会是Cache-Control: max-age=3600, public。

可传递的Cache-Control头类型 #

只要是符合HTTP规范的Cache-Control指令都可以使用，常见的包括：

• no-cache: 强制客户端验证缓存有效性
• no-store: 禁止缓存任何内容
• max-age=xxx: 设置缓存有效期（秒）
• public: 允许任何缓存存储响应
• private: 仅允许客户端缓存响应
• must-revalidate: 缓存过期后必须重新验证

二、验证缓存控制头是否生效 #

可以通过以下几种方式确认Cache-Control头是否正确传递：

1. 浏览器开发者工具
   打开浏览器的「开发者工具」→「网络」标签，发起请求后查看对应响应的「响应头」部分，检查是否存在Cache-Control字段，以及值是否符合预期。

2. curl命令行工具
   使用curl的 verbose 模式查看完整响应头：

   curl -v http://your-esb-service-endpoint
   

   在输出的响应头部分，你会看到类似Cache-Control: no-cache的内容。

3. WSO2 EI日志调试
   启用缓存中介的调试日志：修改repository/conf/log4j2.properties，添加或修改以下配置：

   logger.synapse-cache.name = org.apache.synapse.mediators.cache
   logger.synapse-cache.level = DEBUG
   

   重启EI后，查看repository/logs/wso2carbon.log，可以看到缓存中介处理头的详细过程，确认是否正确添加或修改了Cache-Control头。

4. 序列中添加日志中介
   在响应流中添加日志中介，打印所有响应头：

   <log level="headers"/>
   

   发起请求后，查看EI控制台或日志文件，就能看到响应头的完整内容，检查Cache-Control是否存在。

内容的提问来源于stack exchange，提问作者Francesco Luperto