我剛剛發現部分響應在我們的客戶機器中被緩存爲完整的,導致整個網站無法使用。我完全不知道,那裏有什麼可能出錯的。Firefox存儲緩存不完整響應
那麼在下面的設置中可能會出錯?
在服務器端,我們有一個ASP.NET應用程序在運行。一個IHttpHandler處理對JavaScript文件的請求。它基本上是在請求時縮小文件的大小,並將結果寫入響應流。但是它也記錄該字符串的長度被寫入到Response插播:
String javascript = /* Javascript is retrieved here */;
HttpResponse response = context.Response;
response.ContentEncoding = Encoding.UTF8;
response.ContentType = "application/javascript";
HttpCachePolicy cache = response.Cache;
cache.SetCacheability(HttpCacheability.Public);
cache.SetMaxAge(TimeSpan.FromDays(300));
cache.SetETag(ETag);
cache.SetExpires(DateTime.Now.AddDays(300));
cache.SetLastModified(LastModified);
cache.SetRevalidation(HttpCacheRevalidation.None);
response.Headers.Add("Vary", "Accept-Encoding");
Log.Info("{0} characters sent", javascript.length);
response.Write(javascript);
response.Flush();
response.End();
內容然後通常使用gzip編碼與傳輸編碼分塊發送。對我來說似乎很簡單。
不幸的是,我剛剛和一個用戶進行了遠程會話,其中只有大約1/3的文件在緩存中,當然打破了文件(15k而不是44k)。在緩存中,內容編碼也設置爲gzip,所有通信都通過https進行。
在用戶機器上打開源文件後,我只需按Ctrl-F5,即可立即顯示完整內容。
什麼可能會出錯?
如果它的事項,請找緩存條目從下面的Firefox:
Cache entry information
key: <resource-url>
fetch count: 49
last fetched: 2015-04-28 15:31:35
last modified: 2015-04-27 15:29:13
expires: 2016-02-09 14:27:05
Data size: 15998 B
Security: This is a secure document.
security-info: (...)
request-method: GET
request-Accept-Encoding: gzip, deflate
response-head: HTTP/1.1 200 OK
Cache-Control: public, max-age=25920000
Content-Type: application/javascript; charset=utf-8
Content-Encoding: gzip
Expires: Tue, 09 Feb 2016 14:27:12 GMT
Last-Modified: Tue, 02 Jan 2001 11:00:00 GMT
Etag: W/"0"
Vary: Accept-Encoding
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
Date: Wed, 15 Apr 2015 13:27:12 GMT
necko:classified: 1
更新:經過一段時間,我放棄了。縮小的js文件現在以唯一的名稱寫入文件系統,並由IIS直接提供。這個問題從那以後就沒有發生過。 – Andreas