对同一来源上的其他资源造成副作用的HTTP响应头

我有一个服务器，它为同一主机名上的多个用户托管资源。例如：

我希望允许用户为其目录中的资源指定自己的响应头，类似于在AWS S3上所做的。例如，Carol可能希望她的TODO列表可以从另一个域上的脚本读取，因此她可能希望

访问控制允许源代码：

设置为

TODO.txt

虽然我希望此功能尽可能灵活，但我不能只允许指定任何响应头，因为某些响应头会对整个源或主机名产生副作用。例如，

Set Cookie

可以用于一个人的目录，但是用户代理可以使用Cookie值向其他人的目录发出请求。另一个例子是，用户可以设置

严格的传输安全性

，可能会阻止其他用户使用正常的HTTP

除了请求的资源之外，还有哪些HTTP响应头可能对整个源站产生副作用？到目前为止，我的清单是：

• Alt Svc
• 公钥密码
• 服务器
• 设置Cookie
• 严格的运输安全

---

与其阻止可能影响整个域的响应头，不如推荐一种稍微不同的方法，并指定一个白名单，列出肯定可以使用的响应头。可能存在新的、实验性的或特定于浏览器的标头，这些标头是非标准的，但可能会影响具有特定浏览器的用户的整个域

我建议您使用以下标题是安全的，并且应该是您的用户需要修改的所有内容：

• 访问控制允许源
• 访问控制允许凭据
• 访问控制公开头文件
• 访问控制最大年龄
• 访问控制允许方法
• 访问控制允许标头
• 年龄
• 容许
• 缓存控制
• 内容配置
• 内容编码
• 内容语言
• 内容长度
• 内容位置
• 内容范围
• 内容类型
• 日期
• 埃塔格
• 到期
• 最后修改
• 链接
• 位置
• 布拉格马
• 之后重试
• 传输编码

对于静态内容，如文件和html页面，我不会手动设置内容范围或内容长度。服务器应该自动设置这些头中的许多头。尽管如此，覆盖它们对某些用户来说可能是有意义的。传输编码可用于在传输过程中添加

gzip

或

deflate

（如果服务器支持），但不能与HTTP/2一起使用

---

此外，位置、允许和重试仅对某些状态代码有意义。您可能想省略它们

谢谢您的列表，这确实是我正在考虑的一个选项。我想我还要添加

X-*

。我的一些客户想要一种添加跟踪头之类的方法。