Apache TrafficServer 9.2.8版本中的插件执行顺序问题解析

问题背景

在Apache TrafficServer（ATS）从8.1.11升级到9.2.8版本后，用户遇到了一个关键的插件执行顺序问题。该问题主要涉及header_rewrite插件在请求处理流程中的执行时机变化，导致系统认证流程出现异常。

系统架构分析

用户的系统架构采用了典型的三层代理模式：

1. 前端：Apache TrafficServer作为反向代理
2. 中间层：IBM HTTP Server（IHS）作为Web服务器
3. 后端：实际应用服务器

在这种架构中，认证流程设计为：

• 客户端请求首先到达ATS
• ATS将请求转发至IHS
• IHS再将请求传递到后端应用
• 应用检查认证状态后，会重定向到认证服务器
• 认证完成后，应重定向回ATS URL

问题现象

升级到ATS 9.2.8后，系统出现了以下异常行为：

1. 认证流程中的重定向URL从预期的ATS URL变成了IHS URL
2. 这导致应用服务器认为存在CSRF（跨站请求伪造）攻击而拒绝请求
3. 在8.1.11版本中正常工作的header_rewrite配置在9.2.8中失效

技术原理分析

header_rewrite插件的作用

在8.1.11版本中，用户通过header_rewrite插件设置了以下规则：

cond %{SEND_REQUEST_HDR_HOOK}
set-header Host "trafficserfqdn"

这条规则的作用是在发送请求到后端前，将Host头修改为ATS的域名，确保后端应用生成的URL都基于ATS域名而非IHS域名。

9.2.8版本的变化

在9.2.8版本中，ATS内部处理流程发生了变化：

1. 重映射（remap）操作现在在插件执行之前完成
2. 这导致header_rewrite插件的修改发生在请求已经被重定向到IHS之后
3. 后端应用接收到的是IHS的Host头，因此生成的认证重定向URL也基于IHS域名

解决方案探索

尝试方案1：Lua插件替代

用户尝试使用Lua插件来替代header_rewrite的功能，主要尝试了以下几种方式：

1. 修改请求头：

function do_global_send_request()
  ts.server_request.header["Host"] = "trafficserverurl"
end

2. 修改响应头：

function send_response()
  local jsa = ts.client_response.header['x-jsa-authorization-redirect']
  string.gsub(jsa, 'ihsurl', 'trafficserverfqdn')
  ts.client_response.header['x-jsa-authorization-redirect'] = jsa
end

3. 完整的remap处理：

function send_request()
  ts.server_request.header["Host"] = "trafficserverurl"
end

function send_response()
  local jsa = ts.client_response.header['x-jsa-authorization-redirect']
  string.gsub(jsa, 'ihsurl', 'trafficserverfqdn')
  ts.client_response.header['x-jsa-authorization-redirect'] = jsa
end

function do_remap()
  ts.hook(TS_LUA_HOOK_SEND_REQUEST_HDR, send_request)  
  ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, send_response)
  return 0
end

尝试方案2：配置参数调整

用户还尝试调整ATS的配置参数，特别是proxy.config.url_remap.pristine_host_hdr，这个参数控制是否在重映射过程中保持原始的Host头不变。

根本原因与建议

经过分析，问题的根本原因是ATS 9.2.8版本改变了插件执行顺序，导致header_rewrite插件的修改发生在重映射之后。针对这种情况，建议采取以下解决方案：

1. 优先方案：使用Lua插件在响应阶段直接修改认证重定向URL，这是最可靠的解决方案。

2. 备选方案：调整系统架构，让ATS直接连接到应用服务器，绕过IHS层，但这可能不符合所有部署场景。

3. 长期方案：考虑向ATS社区提交此行为变更的反馈，探讨是否可以在未来版本中提供更灵活的插件执行顺序控制。

实施建议

对于遇到类似问题的用户，建议按照以下步骤排查和解决：

1. 确认当前ATS版本中的插件执行顺序
2. 使用日志记录各阶段的请求/响应头信息
3. 优先考虑使用Lua插件进行细粒度的头信息控制
4. 测试不同配置参数对Host头处理的影响
5. 在生产环境部署前进行全面测试

通过系统性的分析和适当的解决方案，可以确保在ATS 9.2.8及更高版本中维持原有的认证流程正常工作。