对同源其他资源造成副作用的 HTTP 响应 headers
HTTP response headers that cause side effects for other resources on the same origin
我有一台服务器，它为同一主机名上的多个用户托管资源。例如：
我想允许用户为其目录中的资源指定他们自己的响应 headers，类似于在 AWS S3 上所做的。例如，Carol 可能希望她的 TODO 列表可从另一个域上的脚本读取，因此她可能希望 Access-Control-Allow-Origin: * 设置为 todo.txt。
虽然我希望此功能尽可能灵活，但我不能允许仅指定任何响应 headers，因为某些响应 headers 会对整个来源或主机名产生副作用。例如，Set-Cookie 可用于一个人的目录，但用户代理随后可以使用 cookie 值向其他人的目录发出请求。作为另一个示例，用户可以设置 Strict-Transport-Security，可能会阻止其他用户使用普通 HTTP。
还有哪些其他 HTTP 响应 headers 可能对整个来源产生副作用，而不仅仅是请求的资源？到目前为止我的清单：
- Alt-Svc
- Public-Key-Pins
- 服务器
- Set-Cookie
- Strict-Transport-Security
与其阻止可能影响整个域的响应 headers，不如推荐一种稍微不同的方法，并指定一个绝对可以使用的响应 headers 白名单。可能会有新的、实验性的或 browser-specific headers non-standard 但可能会影响使用特定浏览器的用户的整个域。
我建议以下 headers 可以安全使用并且应该是您的用户需要修改的所有内容：
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- 年龄
- 允许
- Cache-Control
- Content-Disposition
- Content-Encoding
- Content-Language
- Content-Length
- Content-Location
- Content-Range
- Content-Type
- 日期
- ETag
- 过期
- Last-Modified
- Link
- 位置
- 编译指示
- Retry-After
- Transfer-Encoding
对于文件和 html 页面等静态内容，我不会手动设置 Content-Range 或 Content-Length。服务器应该自动设置其中的许多 headers。然而，覆盖它们对于某些用户来说可能是有意义的。如果您的服务器支持，Transfer-Encoding 可用于在传输过程中添加 gzip 或 deflate，但不得与 HTTP/2.
一起使用
此外，Location、Allow 和 Retry-After 仅对某些状态代码有意义。你可能想忽略它们
我有一台服务器，它为同一主机名上的多个用户托管资源。例如：
我想允许用户为其目录中的资源指定他们自己的响应 headers，类似于在 AWS S3 上所做的。例如，Carol 可能希望她的 TODO 列表可从另一个域上的脚本读取，因此她可能希望 Access-Control-Allow-Origin: * 设置为 todo.txt。
虽然我希望此功能尽可能灵活，但我不能允许仅指定任何响应 headers，因为某些响应 headers 会对整个来源或主机名产生副作用。例如，Set-Cookie 可用于一个人的目录，但用户代理随后可以使用 cookie 值向其他人的目录发出请求。作为另一个示例，用户可以设置 Strict-Transport-Security，可能会阻止其他用户使用普通 HTTP。
还有哪些其他 HTTP 响应 headers 可能对整个来源产生副作用，而不仅仅是请求的资源？到目前为止我的清单：
- Alt-Svc
- Public-Key-Pins
- 服务器
- Set-Cookie
- Strict-Transport-Security
与其阻止可能影响整个域的响应 headers，不如推荐一种稍微不同的方法，并指定一个绝对可以使用的响应 headers 白名单。可能会有新的、实验性的或 browser-specific headers non-standard 但可能会影响使用特定浏览器的用户的整个域。
我建议以下 headers 可以安全使用并且应该是您的用户需要修改的所有内容：
- Access-Control-Allow-Origin
- Access-Control-Allow-Credentials
- Access-Control-Expose-Headers
- Access-Control-Max-Age
- Access-Control-Allow-Methods
- Access-Control-Allow-Headers
- 年龄
- 允许
- Cache-Control
- Content-Disposition
- Content-Encoding
- Content-Language
- Content-Length
- Content-Location
- Content-Range
- Content-Type
- 日期
- ETag
- 过期
- Last-Modified
- Link
- 位置
- 编译指示
- Retry-After
- Transfer-Encoding
对于文件和 html 页面等静态内容，我不会手动设置 Content-Range 或 Content-Length。服务器应该自动设置其中的许多 headers。然而，覆盖它们对于某些用户来说可能是有意义的。如果您的服务器支持，Transfer-Encoding 可用于在传输过程中添加 gzip 或 deflate，但不得与 HTTP/2.
此外，Location、Allow 和 Retry-After 仅对某些状态代码有意义。你可能想忽略它们