我有一台服务器，它为同一主机名上的多个用户托管资源。例如:
我想允许用户为其目录中的资源指定他们自己的响应 header ，类似于在 AWS S3 上所做的。例如，Carol 可能希望她的 TODO 列表可从另一个域上的脚本读取，因此她可能希望为 todo.txt 设置 Access-Control-Allow-Origin: *。
虽然我希望此功能尽可能灵活，但我不能允许仅指定任何响应 header ，因为某些响应 header 对整个来源或主机名有副作用。例如，Set-Cookie 可用于一个人的目录，但用户代理随后可以使用 cookie 值向其他人的目录发出请求。作为另一个示例，用户可以设置 Strict-Transport-Security，可能会阻止其他用户使用普通 HTTP。
还有哪些其他 HTTP 响应 header 可能对整个来源产生副作用，而不仅仅是请求的资源？到目前为止我的 list :
- Alt-Svc
- 公钥密码
- 服务器
- 设置 Cookie
- 严格的运输安全
最佳答案
与其阻止可能影响整个域的响应 header ，不如推荐一种稍微不同的方法，并指定一个绝对可以使用的响应 header 白名单。可能会有新的、实验性的或特定于浏览器的非标准 header ，但可能会影响使用特定浏览器的用户的整个域。
我建议以下 header 可以安全使用，并且应该是您的用户需要修改的所有内容:
- 访问控制允许来源
- 访问控制允许凭据
- 访问控制公开 header
- 访问控制最大年龄
- 访问控制允许方法
- 访问控制允许 header
- 年龄
- 允许
- 缓存控制
- 内容处置
- 内容编码
- 内容语言
- 内容长度
- 内容位置
- 内容范围
- 内容类型
- 日期
- 电子标签
- 过期
- 最后修改时间
- 链接
- 地点
- 语用
- 之后重试
- 传输编码
对于文件和 html 页面等静态内容，我不会手动设置 Content-Range 或 Content-Length。服务器应该自动设置其中的许多 header 。然而，覆盖它们对于某些用户来说可能是有意义的。如果您的服务器支持，Transfer-Encoding 可用于在传输过程中添加 gzip 或 deflate，但不得与 HTTP/2 一起使用。
此外，Location、Allow 和 Retry-After 仅对某些状态代码有意义。你可能想忽略它们
关于对同源其他资源造成副作用的 HTTP 响应 header ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/48059331/