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