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

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

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

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

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

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

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