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 生效