Squid 的 URL 重写器能修改响应正文吗？
在扩展正向代理时，请把请求 URL 的选择与响应适配、TLS 解密分开。
url_rewrite_program 处理的是请求 URL 的决策。它接收请求信息，并通过 Squid 的辅助程序协议回复；它不会拿到一个已下载的文件去改写再返回。
| 想要执行的操作 | 相关的边界 |
|---|---|
| 重定向浏览器或另选一个请求 URL | URL 重写辅助程序在请求阶段承担的职责 |
| 修改可见的 HTTP 响应正文 | 响应适配机制，例如已配置的 ICAP 响应修改 |
| 在普通 CONNECT 内部读取 HTTP | 必须先在与部署方式相称的安排下终止目标端的 TLS |
| 解密由应用自身加密的文件 | 取决于文件格式、算法与密钥，与传输方式无关 |
最后两行很容易混淆。通过 HTTPS 传输的普通文件由 TLS 保护。由应用加密的文件即使在 HTTPS 被终止之后仍可能保持加密。选择一套适配接口，既不会提供应用的密钥，也不会提供它的解密算法。
普通 CONNECT 转发的只是加密隧道的字节。URL 辅助程序不会暴露内部响应；需要检查的设计必须先确定这类流量在部署中能否、是否应当解密。
在 Squid 能够检查 HTTP 报文的地方，响应修改服务仍然要对内容编码、改变后的长度以及失败时的行为负责。请在定义好变换之后再选择接口，而不是把一个能工作的 URL 重写示例扩展到它永远不会收到的处理阶段。