Django4.0 緩存框架-下游緩存

到目前為止，本文檔的重點是緩存您自己的數(shù)據(jù)。 但是另一種類型的緩存也與 Web 開發(fā)相關：由“下游”緩存執(zhí)行的緩存。 這些系統(tǒng)甚至在請求到達您的網(wǎng)站之前就為用戶緩存頁面。

下面是一些下游緩存的例子：

• 使用 HTTP 時，您的 ISP 可能會緩存某些頁面，因此如果您從 http://example.com/ 請求頁面，您的 ISP 將向您發(fā)送該頁面，而無需直接訪問 example.com。 example.com 的維護者不知道這種緩存； ISP 位于 example.com 和您的 Web 瀏覽器之間，透明地處理所有緩存。 這種緩存在 HTTPS 下是不可能的，因為它會構成中間人攻擊。
• 您的 Django 網(wǎng)站可能會在一個代理緩存的后面，例如Squid 網(wǎng)頁代理緩存，為了性能而緩存頁面。在這種情況下，每個請求首先由代理來處理，只有在需要時才將其傳遞給應用程序。
• 您的網(wǎng)絡瀏覽器也會緩存頁面。 如果網(wǎng)頁發(fā)送了適當?shù)臉祟^，您的瀏覽器將使用本地緩存副本來處理對該頁面的后續(xù)請求，甚至無需再次聯(lián)系該網(wǎng)頁以查看它是否已更改。

下游緩存是一個很好的效率提升，但它存在一個危險：許多網(wǎng)頁的內容基于身份驗證和許多其他變量而有所不同，并且緩存系統(tǒng)盲目地僅基于 URL 保存頁面可能會將不正確或敏感的數(shù)據(jù)暴露給后續(xù)這些頁面的訪問者。

例如，如果您使用網(wǎng)絡電子郵件系統(tǒng)，那么收件箱頁面的內容取決于登錄的用戶。如果 ISP 盲目緩存您的站點，那么通過該 ISP 登錄的第一個用戶將擁有他們的用戶 - 為該站點的后續(xù)訪問者緩存的特定收件箱頁面。

幸運的是，HTTP 為這個問題提供了解決方案。存在許多 HTTP 報頭以指示下游緩存根據(jù)指定的變量來區(qū)分它們的緩存內容，并且告訴緩存機制不緩存特定的頁面。