Apache 默认不传递 Authorization头到后端环境（如 PHP）。其表现是：
print_r($_SERVER)时， 没有 [Authorization] ：
Array
(
[Accept-Language] => zh,en;q=0.9,zh-CN;q=0.8,en-US;q=0.7
[Accept-Encoding] => gzip, deflate
[Referer] => http://www.ysp3.cn/
[Origin] => http://www.ysp3.cn
[Accept] => */*
[User-Agent] => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36
[Connection] => close
[Host] => www.wzypsi.cn
[Authorization] => Bearer 104203|tSD4KqTw422N9WbfJmaQbflcoNAixw3MG9NbWJIg
)主要基于安全性和协议规范的考量。以下是其设计动机的详细分析：
🔒 一、核心设计动机
-
安全风险控制
Authorization头通常包含敏感身份凭证（如 Basic Auth 的 Base64 编码密码、Bearer Token 等）。若默认传递这些信息到后端脚本（如 PHP），可能被恶意脚本或漏洞利用，导致凭证泄露。
案例：共享主机环境中，多个用户共享同一 Apache 实例，传递该头可能被其他用户的脚本窃取。 -
遵循 CGI/FastCGI 协议规范
CGI 规范（RFC 3875）明确要求过滤敏感头字段 （如
Authorization和Cookie），仅保留与请求处理直接相关的头（如User-Agent）
Apache 作为中间层，需遵循此规范以保障兼容性。 -
减少攻击面
默认过滤可避免后端应用因未正确处理敏感头而引发的安全漏洞（如日志记录敏感头、错误信息泄露等）
例如：若 PHP 应用未加密日志，Authorization头可能被写入日志文件。 -
性能优化
非认证请求（如静态资源）无需解析
Authorization头，过滤可减少不必要的资源开销。
⚖️ 二、实际影响与开发者困境
-
API 开发受阻
现代 API 依赖
Authorization头传递 Token（如 JWT），若 Apache 默认过滤，后端无法获取认证信息，导致 401 错误。开发者误区：常误以为是代码错误，而非服务器配置问题。 -
环境差异性问题
Apache 与其他服务器（如 Nginx）行为不一致：Nginx 默认传递该头，导致开发环境（Nginx）正常而生产环境（Apache）失败。
🔧 三、解决方案与设计妥协
为解决上述问题，Apache 提供显式配置选项，允许开发者按需传递该头：
-
.htaccess配置SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1 [1,5](@ref)原理：通过正则捕获
Authorization头内容，注入HTTP_AUTHORIZATION环境变量（PHP 可通过$_SERVER['HTTP_AUTHORIZATION']访问） -
mod_rewrite方案RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] [3](@ref)适用场景：需处理 URL 重写时同步传递该头。
💎 四、总结：安全与灵活的平衡
| 设计原则 | 具体表现 | 用户影响 |
|---|---|---|
| 安全性优先 | 默认过滤敏感头，减少凭证泄露风险 | 后端需显式配置以获取 Authorization头 |
| 协议合规性 | 遵循 CGI 规范，避免兼容性问题 | 开发者需理解服务器行为差异 |
| 按需灵活性 | 提供 SetEnvIf等配置，允许安全场景下传递敏感头 |
配置简单但需重启 Apache 生效 |
这一设计体现了 "默认安全"原则（Secure by Default），即默认关闭高风险功能，仅在用户明确需求时启用。尽管增加了开发者的配置成本，但有效降低了系统级安全风险。