緩存控制問題

如果我設置爲我的網站上高速緩存控制：緩存控制問題

Header unset Pragma 
FileETag None 
Header unset ETag 

# 1 YEAR 
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4)$"> 
Header set Cache-Control "public" 
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT" 
Header unset Last-Modified 
</FilesMatch> 

# 2 HOURS 
<FilesMatch "\.(html|htm|xml|txt|xsl)$"> 
Header set Cache-Control "max-age=7200, must-revalidate" 
</FilesMatch> 

# CACHED FOREVER 
# MOD_REWRITE TO RENAME EVERY CHANGE 
<FilesMatch "\.(js|css)$"> 
Header set Cache-Control "public" 
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT" 
Header unset Last-Modified 
</FilesMatch>

...那麼如果我更新任何CSS或圖片或其他文件，將用戶的瀏覽器仍然使用緩存版本，直到它會過期（一年後）？

由於

來源

2010-09-29 3zzy

你的CSS，JS和圖像文件將永遠不會被緩存，爲你設置一個日期過去。

我認爲這是一個錯誤，並且您打算將其設置爲未來一年，這是支持max-age過期的一個原因。

如果是這樣的話，那麼你的圖片將被緩存高達一年。可以隨時從緩存中刪除某些內容，例如清理不常用的條目以減少緩存佔用的磁盤大小。

有兩種可能的方法來處理降低陳舊風險的可能性。一種是設置更低的到期時間，並使用電子標籤和修改日期，以便在到期時間過去之後，如果沒有變化，您可以發送304，所以服務器只需要發送幾個字節而不是整個實體。

另一個是保持到期一年，但要更改改變時使用的URI。例如，這可以是有用的。一個大型文件，幾乎在您網站的每個頁面上使用。它要求你改變所有對該資源的引用，因爲它確實改變了（因爲你基本上正在改變使用新的資源），這可以很費勁，因此只在少數熱點情況下被建議作爲優化。如果某個文件忽略查詢屬性（例如，它只是直接從文件中提供），瀏覽器將不會知道該屬性，因此您可以使用類似/scripts/bigScript.js?version=1.2.3的內容，然後在更改bigScript.js時更改爲/scripts/bigScript.js?version=1.2.4。這對bigScript.js沒有任何影響，但會導致瀏覽器獲得一個新文件，因爲它知道它是一個完全不同的資源。

來源

2010-10-02 17:25:52

啊哈，所以如果我設置過期到一年或'遠期未來'，並incase我不得不改變一些緩存的文件，我只會添加像'style.css？ver = 031010'的屬性，它會抓住這個新文件？此操作是否跨瀏覽兼容？ – 3zzy 2010-10-03 04:35:48

它完全跨瀏覽器兼容。請記住，對於所有的瀏覽器都知道，服務器使用該查詢字符串 - 因此它不能假定style.css？ver = 020123與style.css？ver = 031010相同，必須重新獲取文件。服務器正在使用相同的文件（只有更新版本的課程）並忽略查詢字符串，但它可能會做其他事情。只有重擊「庫」文件才值得。 – 2010-10-03 12:02:04

太棒了，就是我想知道的。謝謝！另外，我的靜態文件（CSS，圖像）與HTML所在的域不在同一個域中，因此htaccess的位置在哪裏？ – 3zzy 2010-10-04 05:12:42

是的，在未來的一個response with an expiration date將被視爲新鮮直到有效期限：

過期實體頭字段給出的日期/時間之後，響應被視爲失效。 [...]

未來某個時間的日期值的Expires標頭字段在默認情況下默認爲不可緩存的響應中表示該響應是可緩存的，除非由Cache-控制標題字段（section 14.9）。

注意，到期日一年以上，將來可能被解釋爲永不過期：

標記爲「永不過期」，響應的原始服務器發送一個到期日期從答覆發送之日起大約一年。 HTTP/1.1服務器不應在將來發送超過一年的過期日期。

因此，如果緩存中存儲的響應，可能將需要從緩存響應，即使沒有重新確認發送之前緩存的響應。

現在，如果你更改資源是already stored in caches and still fresh, there is no way to invalidate them：

[...]雖然他們可能會繼續以「新鮮，」他們沒有準確反映原始服務器將返回上一個新的請求資源。

HTTP協議無法保證所有此類緩存條目都被標記爲無效。例如，導致原始服務器發生更改的請求可能沒有經過存儲緩存條目的代理。

這是爲什麼這樣從來沒有到期的資源用在與每個更新改變網址（例如style-v123.css）唯一的版本號的原因。這也是我在這種情況下推薦的。

順便說一句，在這種情況下聲明與Cache-Control as public的迴應沒有做任何事情。這僅在需要授權的響應應該可緩存時纔會使用：

public - 指示響應可以被任何緩存緩存，即使緩存通常不可緩存或僅緩存在非共享內緩存。（另請參閱授權，section 14.8，瞭解更多詳情。）

有關HTTP緩存的更多信息：

來源

2010-09-29 10:50:54 Gumbo

緩存控制問題

回答

相關問題