☰

HTTP 標頭是由 CDN 還是由應用程式配置？

tag-icon • tag-icon http-headers cdn
HTTP 標頭是由 CDN 還是由應用程式配置？

這是一個理論問題，我想它可能太廣泛或不清楚。

Foobar 是一個為網路上的使用者提供服務的應用程式。它依靠 CDN 來提高其彈性、速度等，以便為無論身在何處的人們提供服務。

  • HTTP 標頭（由客戶端接收）是由 CDN 還是由 Foobar 應用程式定義（意味著 CDN 將轉送它們）？

  • 如果兩者都可以，那麼兩者的優缺點是什麼？

答案1

沒有普遍的答案。使用標頭完成的操作取決於請求、特定 CDN、特定標頭和您的網站配置（包括後端/來源伺服器在回應中包含的標頭以及您在 CDN 中配置網站的方式）。

假設預設情況下大多數標頭將被剝離來自後端/原始伺服器產生的回應，並且只有（最小）將設定標頭子集在 CDN 發送的回應中。

一些（CDN 特定的）標頭可能是添加由 CDN 根據您的策略或預設情況提供。例如快速新增一個x-served-by:標頭 預設情況下，CloudFront 允許您設定和可選 Server-Timing:標頭方便調試CDN操作。

一些標題可能是保留來自您的後端伺服器。例如Cache-control:， 和Expires:標題是相當常見的。請參閱範例：雲端前端文檔

一些可能是調整過的由 CDN 以特定方式提供。例如，看看 Fastly 如何處理Date:標頭設定在原點。

在 CDN 上設定標頭的原因

您不是允許每個應用程式執行自己的操作，或不執行任何操作，而是在 CDN 層級為所有網站和應用程式設定單一策略。

好的例子是跨域資源共享和HSTS政策。

當來源沒有設定/新增特定標頭時，您可以選擇僅在 CDN 上設定/新增特定標頭，但如果在來源中設定了該值，則使用來自來源的值。

等等等等

保留在源頭設定的標頭的原因

應用程式（開發人員）最了解應用程式的需求。

使用 a 覆蓋預設快取策略Cache-Control: private, no-store是我想到的教科書範例。

等等等等

相關內容