☰

HTTP 标头是由 CDN 还是由应用程序配置？

tag-icon • tag-icon http-headers cdn
HTTP 标头是由 CDN 还是由应用程序配置？

这是一个理论性的问题，我猜它可能太宽泛或太不清楚。

Foobar 是一款为互联网用户提供服务的应用程序。它依靠 CDN 来提高其弹性、速度等，以便为世界各地的人们提供服务。

  • HTTP 标头（由客户端接收）是由 CDN 定义，还是由 Foobar 应用程序定义（暗示 CDN 将转发它们）？

  • 如果两种方式均可行，那么各自的优缺点是什么？

答案1

没有统一的答案。使用/针对标头执行的操作取决于请求、特定 CDN、特定标头和您的站点配置（包括后端/原始服务器在响应中包含的标头以及您在 CDN 中配置站点的方式）。

假设默认情况下大多数标题将被删除来自后端/原始服务器生成的响应，并且只有（最小）将设置标题子集在 CDN 发送的响应中。

一些（特定于 CDN 的）标头可能是添加根据您的策略或默认设置由 CDN 提供。例如，Fastly 添加了x-served-by:标题 默认情况下，CloudFront 允许您设置和可选 Server-Timing:标题以便于调试CDN操作。

一些标题可能是保存来自您的后端服务器。例如Cache-control:和Expires:标头是相当常见的标头。例如，请参见：Cloud Front 文档

一些可能是已调整CDN 以特定方式处理。例如，看看 Fastly 如何处理Date:标题设置在原点。

在 CDN 上设置标头的原因

您不需要允许每个应用程序执行自己的事情或者不执行任何操作，而是在 CDN 级别为所有站点和应用程序设置单一策略。

很好的例子是CORS和高速传输系统政策。

您可以选择仅在原点没有设置/添加特定标头时在 CDN 上设置/添加特定标头，但如果在原点设置了该标头，则使用原点的值。

等等等等

保留在原点设置的标头的原因

应用程序（开发人员）最了解应用程序需要什么。

用覆盖默认缓存策略Cache-Control: private, no-store是一个我想到的教科书示例。

等等等等

相关内容