Clear-Site-Data头必须由后端业务逻辑在成功注销后主动设置，Apache仅负责透传；错误地在中无条件添加该头会导致非真实退出场景误清数据，且值必须严格为"cache,cookies,storage,executionContexts"（无空格），并使用Header always set确保302等跳转响应也生效。
Apache 本身不支持直接在响应中设置 Clear-Site-Data 头来触发浏览器清除数据——它能发这个头，但**必须由后端业务逻辑决定何时发送**，不能靠 mod_headers “自动拦截 /logout 路径就塞头”。强行在 Location 块里无条件加 Header，会导致非退出场景误清数据，用户刷新页面就丢登录态。
Clear-Site-Data 必须由业务响应主动触发
浏览器只在收到包含 Clear-Site-Data 的 HTTP 响应时执行清理，且该响应必须是用户真实发起的退出请求（如 POST /logout）所返回的。mod_headers 没有判断请求体内容或业务状态的能力，无法区分“真退出”和“假访问”。
- 常见错误：在
Header always set Clear-Site-Data "cache, cookies, storage, executionContexts"—— 这会让所有 GET /logout（比如前端路由跳转、爬虫探测）都触发清理，极其危险 - 正确做法：后端在成功处理退出逻辑后，显式输出该响应头。Apache 只负责透传或补全，不越权决策
- 如果后端无法改代码（如老旧 PHP 应用），可用
mod_rewrite+SetEnvIf做有限识别，但仅适用于简单场景（如匹配特定 URL + 方法 + 无参数）
Apache 配置需配合后端，且注意值格式与兼容性
即使后端已设头，Apache 仍可能因配置不当导致头被覆盖、截断或忽略。关键点：
Apache Tika Content Extraction Hub
下载
通过Apache Tika Server REST API从1400多种文件格式中提取文本和元数据。处理PDF、DOCX、PPTX、电子邮件归档以及带有MIME类型检测的嵌入式文档提取。
-
Clear-Site-Data值必须严格匹配规范：只能是"cache"、"cookies"、"storage"、"executionContexts"的组合，用英文逗号分隔，**前后不能有空格**；常见错写成"cache, cookies"（带空格）会导致浏览器静默忽略 - 必须用
Header always set，不能用Header set——后者只对 2xx/3xx 响应生效，而退出接口可能返回 302 跳转，此时头会丢失 - 确保
mod_headers已启用：a2enmod headers，并确认没有其他模块（如某些安全模块）在后期 unset 该头 - 部分旧版浏览器（Chrome
安全边界：禁止对非退出路径透传或伪造该头
有人试图用 Header echo 或 RequestHeader 把客户端传来的 Clear-Site-Data 头原样回写，这是严重漏洞——攻击者可构造恶意请求强制清目标站点数据。
- Apache 必须禁用任何来自客户端的
Clear-Site-Data头透传：RequestHeader unset Clear-Site-Data - 不要在全局或目录块中无条件设置该头，哪怕加了
- 若使用反向代理（如 Apache → Node.js），确保
ProxyPreserveHost On不影响头传递，且后端返回的Clear-Site-Data不被代理层过滤
真正可靠的“一键退出清理”，核心不在 Apache 配置多复杂，而在于后端是否在认证销毁完成后，精确、可控地发出那个头——Apache 只是信道，不是决策者。最容易被忽略的是：退出响应必须是最终响应（非重定向中间跳转），且头值字符串不能含非法字符或空格。
