❶ 請問網頁的緩存清除在java代碼中怎麼解決
IE總是彈出腳本錯誤提示窗口
出現此問題是因為該網頁的 HTML 源代碼不能使用客戶端腳本（如 Microsoft JScript 或 Visual Basic 腳本）正確工作。發生此問題可能是因為以下原因之一： " 網頁的 HTML 源代碼中有問題。
" 您的計算機或網路上阻止了活動腳本、ActiveX 控制項或 Java 小程序。Internet Explorer 或另外一種程序（如防病毒程序或防火牆）可以配置為阻止活動腳本、ActiveX 控制項或 Java 小程序
" 防病毒軟體配置為掃描您的「臨時 Internet 文件」或「已下載的程序文件」文件夾。
" 您計算機上的腳本引擎損壞或過時。
" 您計算機上的 Internet 相關文件夾損壞。
" 您的視頻卡驅動程序已損壞或者已過時。
" 您計算機上的 DirectX 組件損壞或過時。
注意：伺服器端腳本 -- 如 Active Server Pages (ASP) 中的 Visual Basic 腳本 -- 運行在 Web 伺服器上。因伺服器端腳本故障而發生的腳本錯誤不在 Internet Explorer 中生成錯誤消息，但也可能會創建一個不能正確顯示或工作的網頁。
一、錯誤特徵:
行: 247 字元: 2 錯誤: 拒絕訪問 代碼: 0
二、解決方案
1、清除一下IE瀏覽器的緩存,點IE上的工具——然後再選擇最下面的Internet選項，再點Internet刪除文件(記得勾上刪除所有離線內容)，確定後再重新打開IE瀏覽器試試,同時請確認您使用的是IE6.0及以上版本。
2、您的網頁上清緩存,在網頁上選擇工具->Interner選項->刪除Cookies和刪除文件,然後再確定。
3、請您點擊IE瀏覽器中的「工具」，選擇「internet選項」，進入「安全」頁面，點擊「自定義級別」，將您的安全設置設為「低」。
4、清空一下IE瀏覽器的cookies文件，在IE瀏覽器中設置「禁止自動腳本更新」，並不要選擇「禁止運行ActiveX控制項」，然後再嘗試操作。
三、總結1、錯誤類型不固定 行: 247 字元: 2 錯誤: 拒絕訪問 代碼: 0 數字部分都是可變的。
2、解決方案中的4條不用都改，我的錯誤只用了1、2條就解決了。
如果有頁面出現腳本錯誤，就把他另存，然後一點點刪除，如果當你刪除一段代碼後不再出現腳本錯誤，那就是那一段代碼出現問題，如果那段代碼不重要或是根本不需要，你就可以直接刪除；如果那段代碼很重要，那可以找段代碼代替。不過我還是建議你加幾個網頁方面的Ｑ群，裡面有很多深藏不露的高手。可以在網上直接搜到
❷ 緩存Cache-Control
首先附上前面提到的一張圖：
根據上面的這張圖，來說http協議中的緩存，也就是cache-control將會格外清晰。
Cache-Control包括哪些特性呢？
第一，可緩存性：public private no-cache 。可緩存性指http的response進過的哪些地方可以進行緩存。public指在response返回經過的任何地方都可以緩存，包括代理伺服器，客戶端等，這樣下次請求將不會到達服務端而直接返回response；private則表示只有返回的瀏覽器才可以進行緩存；no-cache則表示不可直接用緩存，而是先要到伺服器端進行驗證。
第二，到期：max-age=<seconds> ，代表緩存的時間(秒)； s-maxage=<seconds> ,專門為代理伺服器設置，如果與max-age同時返回，則瀏覽器會讀取max-age，而代理伺服器則會讀取s-maxage這個設置； max-stale=<seconds> ，代表在max-age過期後，如果存在max-stale，而且其時間沒有過期，則表示仍然可以用緩存，max-stale只在request發起端設置是有用的，又因為瀏覽器不會幫助我們帶上這個頭，所以客戶端是瀏覽器的時候這個max-stale是用不到的。
第三，重新驗證：must-revalidate和proxy-revalidate ，這兩個表示緩存過期時間到達以後，必須要到服務端重新請求和重新驗證，這兩個屬性在瀏覽器也不怎麼出現。
第四，其他，no-store ，表示本地和代理伺服器都不可以用緩存，必須去重新獲取； no-transform ，告訴代理伺服器不要對返回的body進行處理，比如壓縮等（代理伺服器比如nginx等可以不遵守，但是這個是規范，最好遵守）。
下面附上做的幾個簡單的例子來加深對上面的理解 。例子中通過查看對文件script.js的緩存情況說明問題。
執行node server.js，觀察瀏覽器network如下圖（這里注意，瀏覽器的Disable cache沒有勾選，否則會默認忽略Cache-Control的設置）：
立刻重新刷新瀏覽器，則network中出現下圖：
此時我們可以看見這事size一欄是from memory cache，因為我們設置max-age為20s，在這個期間即使我改變script.js的內容，瀏覽器仍然會用memory裡面的內容，而得不到更新。很顯然實際開發中，如果出現這樣的問題，是很可怕的。同時如果每次去後端請求response，又會使網頁很慢， 實際中max-age往往要設置很大 ，表示在本地保存很久的時間，那麼下次請求的Time為0。那麼實際開發中，如何去解決這兩者的矛盾呢？就是通過改變url的方法， 在請求的文件名後面加上根據內容生成的哈希值 （刷新瀏覽器緩存的方案），這樣實際請求的 url將會改變，那麼自然就會去重新請求，如果後端的文件沒有更新，也就是url沒有變，則自然會在緩存中讀取，則不需要經過網路傳輸，則速度是很快的，用戶體驗是很好的。 network一欄中，這里Size的兩個值，上面表示傳輸時候的大小，下面表示實際的大小（上面的可進行壓縮Gzip傳輸，但是不曉得header可不可以壓縮，貌似http2中支持頭壓縮），傳輸時的大小比實際的大，因為加上了頭信息。Time的兩個值，上面一行表示從請求開始到接受完最後一個byte為止的時間。下面一行是Latency，代表從請求接受完到讀取該資源第一個byte之間的等待時間。
上圖是查找緩存的過程。
如果Cache-Control中max-age的值設置很大，那麼一直用本地的緩存肯定是不可取的。所以除了給文件名後面加上哈希碼之外的方法，我們可以通過每次去後端詢問是否文件有所改動？那麼如何來實現這個過程呢？首先在Cache-Control中設置no-cache，同時遵從實際情況我們把max-age設置很大。更改servr.js如下：
打開network，多次刷新仍然如下：
說明此時已經不在緩存中讀取了，即使我們的max-age設置很大，這是因為我們設置了no-cache。所以每次我們都不會直接使用緩存了。那麼如何發揮no-cache的作用呢，還需要配合資源驗證，資源驗證在http中主要有兩個頭:Last-Modified和Etag。這個內容介紹在-資源驗證Last-Modified和Etag中介紹。
❸ 協商緩存和強緩存的區別
協商緩存和強緩存的區別
（1）強緩存
使用強緩存策略時，如果緩存資源有效，則直接使用緩存資源，不必再向伺服器發起請求。
強緩存策略可以通過兩種方式來設置，分別是 http 頭信息中的 Expires 屬性和 Cache-Control 屬性。
（1）伺服器通過在響應頭中添加 Expires 屬性，來指定資源的過期時間。在過期時間以內，該資源可以被緩存使用，不必再向伺服器發送請求。這個時間是一個絕對時間，它是伺服器的時間，因此可能存在這樣的問題，就是客戶端的時間和伺服器端的時間不一致，或者用戶可以對客戶端時間進行修改的情況，這樣就可能會影響緩存命中的結果。
（2）Expires 是 http1.0 中的方式，因為它的一些缺點，在 HTTP 1.1 中提出了一個新的頭部屬性就是 Cache-Control 屬性，它提供了對資源的緩存的更精確的控制。它有很多不同的值，
Cache-Control可設置的欄位：
public：設置了該欄位值的資源表示可以被任何對象（包括：發送請求的客戶端、代理伺服器等等）緩存。這個欄位值不常用，一般還是使用max-age=來精確控制；
private：設置了該欄位值的資源只能被用戶瀏覽器緩存，不允許任何代理伺服器緩存。在實際開發當中，對於一些含有用戶信息的HTML，通常都要設置這個欄位值，避免代理伺服器(CDN)緩存；
no-cache：設置了該欄位需要先和服務端確認返回的資源是否發生了變化，如果資源未發生變化，則直接使用緩存好的資源；
no-store：設置了該欄位表示禁止任何緩存，每次都會向服務端發起新的請求，拉取最新的資源；
max-age=：設置緩存的最大有效期，單位為秒；
s-maxage=：優先順序高於max-age=，僅適用於共享緩存(CDN)，優先順序高於max-age或者Expires頭；
max-stale[=]：設置了該欄位表明客戶端願意接收已經過期的資源，但是不能超過給定的時間限制。
一般來說只需要設置其中一種方式就可以實現強緩存策略，當兩種方式一起使用時，Cache-Control 的優先順序要高於 Expires。
no-cache和no-store很容易混淆：
no-cache 是指先要和伺服器確認是否有資源更新，在進行判斷。也就是說沒有強緩存，但是會有協商緩存；
no-store 是指不使用任何緩存，每次請求都直接從伺服器獲取資源。
（2）協商緩存
如果命中強制緩存，我們無需發起新的請求，直接使用緩存內容，如果沒有命中強制緩存，如果設置了協商緩存，這個時候協商緩存就會發揮作用了。
上面已經說到了，命中協商緩存的條件有兩個：
max-age=xxx 過期了
值為no-store
使用協商緩存策略時，會先向伺服器發送一個請求，如果資源沒有發生修改，則返回一個 304 狀態，讓瀏覽器使用本地的緩存副本。如果資源發生了修改，則返回修改後的資源。
協商緩存也可以通過兩種方式來設置，分別是 http 頭信息中的Etag 和Last-Modified屬性。
（1）伺服器通過在響應頭中添加 Last-Modified 屬性來指出資源最後一次修改的時間，當瀏覽器下一次發起請求時，會在請求頭中添加一個 If-Modified-Since 的屬性，屬性值為上一次資源返回時的 Last-Modified 的值。當請求發送到伺服器後伺服器會通過這個屬性來和資源的最後一次的修改時間來進行比較，以此來判斷資源是否做了修改。如果資源沒有修改，那麼返回 304 狀態，讓客戶端使用本地的緩存。如果資源已經被修改了，則返回修改後的資源。使用這種方法有一個缺點，就是 Last-Modified 標注的最後修改時間只能精確到秒級，如果某些文件在1秒鍾以內，被修改多次的話，那麼文件已將改變了但是 Last-Modified 卻沒有改變，這樣會造成緩存命中的不準確。
（2）因為 Last-Modified 的這種可能發生的不準確性，http 中提供了另外一種方式，那就是 Etag 屬性。伺服器在返回資源的時候，在頭信息中添加了 Etag 屬性，這個屬性是資源生成的唯一標識符，當資源發生改變的時候，這個值也會發生改變。在下一次資源請求時，瀏覽器會在請求頭中添加一個 If-None-Match 屬性，這個屬性的值就是上次返回的資源的 Etag 的值。服務接收到請求後會根據這個值來和資源當前的 Etag 的值來進行比較，以此來判斷資源是否發生改變，是否需要返回資源。通過這種方式，比 Last-Modified 的方式更加精確。
當 Last-Modified 和 Etag 屬性同時出現的時候，Etag 的優先順序更高。使用協商緩存的時候，伺服器需要考慮負載平衡的問題，因此多個伺服器上資源的 Last-Modified 應該保持一致，因為每個伺服器上 Etag 的值都不一樣，因此在考慮負載平衡時，最好不要設置 Etag 屬性。
總結：
強緩存策略和協商緩存策略在緩存命中時都會直接使用本地的緩存副本，區別只在於協商緩存會向伺服器發送一次請求。它們緩存不命中時，都會向伺服器發送請求來獲取資源。在實際的緩存機制中，強緩存策略和協商緩存策略是一起合作使用的。瀏覽器首先會根據請求的信息判斷，強緩存是否命中，如果命中則直接使用資源。如果不命中則根據頭信息向伺服器發起請求，使用協商緩存，如果協商緩存命中的話，則伺服器不返回資源，瀏覽器直接使用本地資源的副本，如果協商緩存不命中，則瀏覽器返回最新的資源給瀏覽器。
❹ asp.net怎麼設置瀏覽器客戶端緩存
1. Expires:+過期時間
表示在指定時間後瀏覽器緩存失效，需要注意的是這兒的過期時間必須是HTTP格式的日期時間，其他的都會被解析成當前時間「之前」，緩存會馬上過期，HTTP的日期時間必須是格林威治時間（GMT），而不是本地時間。舉例：
❺ 認識HTTP----緩存篇
本文內容大多參考 《圖解HTTP》一書
所以講緩存為什麼要先扯代理伺服器？別急，讓我們看一下一個請求的簡單示意圖。
我們看到客戶端(用戶)發送了一個請求並不是直接發給源伺服器的而是經過了代理伺服器，然後經由代理伺服器再發送給源伺服器，響應也同樣遵循這個順序。
那麼代理伺服器在這中間擔任了什麼角色？
緩存是指代理伺服器或客戶端本地磁碟內保存的資源副本。利用緩存可減少對源伺服器的訪問，因此也就節省了通信流量和通信時間。
緩存伺服器是代理伺服器的一種，並歸類在緩存代理類型中。換句話說，當代理轉發從伺服器返回的響應時，代理伺服器將會保存一份資源的副本。
緩存伺服器的優勢在於利用緩存可避免多次從源伺服器轉發資源。因此客戶端可就近從緩存伺服器上獲取資源，而源伺服器也不必多次處理相同的請求了。
即便緩存伺服器和客戶端內有緩存，也不能每次都給我返回緩存吧，如果是這樣，源伺服器更新了我也不知道，因為我每次都是看緩存的資源。
為了解決這個問題，針對緩存設計了時效性的概念：
即使存在緩存，也會因為客戶端的要求、緩存的有效期等因素，向源伺服器確認資源的有效性。若判斷緩存失效，緩存伺服器將會再次從源伺服器上獲取「新」資源。
緩存不僅可以存在於緩存伺服器內，還可以存在客戶端瀏覽器中。以Internet Explorer 程序為例，把客戶端緩存稱為臨時網路文件（Temporary Internet File）。
瀏覽器緩存如果有效，就不必再向伺服器請求相同的資源了，可以直接從本地磁碟內讀取。
另外，和緩存伺服器相同的一點是，當判定緩存過期後，會向源伺服器確認資源的有效性。若判斷瀏覽器緩存失效，瀏覽器會再次請求新資源。
Pragma 是HTTP/1.1 之前版本的歷史遺留欄位，僅作為與HTTP/1.0的向後兼容而定義。
規范定義的形式唯一，如下所示。
Pragma: no-cache
該首部欄位屬於通用首部欄位，但只用在客戶端發送的請求中。客戶端會要求所有的中間伺服器不返回緩存的資源。
通過指定首部欄位Cache-Control 的指令，就能操作緩存的工作機制。
可用的指令按請求和響應分類如下所示:
public指令
Cache-Control: public
當指定使用public 指令時，則明確表明其他用戶也可利用緩存。
private指令
no-store指令
Cache-Control: no-store
當使用no-store 指令時，暗示請求（和對應的響應）或響應中包含機密信息。
因此，該指令規定緩存不能在本地存儲請求或響應的任一部分。
ps:從字面意思上很容易把no-cache誤解成為不緩存，但事實上no-cache代表不緩存過期的資源，緩存會向源伺服器進行有效期確認後處理資源，也許稱為do-not-serve-from-cache-without-revalidation更合適。no-store 才是真正地不進行緩存，請讀者注意區別理解。
s-maxage指令
Cache-Control: s-maxage=604800 //（單位：秒）
s-maxage 指令的功能和max-age 指令的功能相同， 它們的不同點是s-maxage 指令只適用於供多位用戶使用的公共緩存伺服器(這里指代理伺服器)。也就是說，對於向同一用戶重復返回響應的伺服器來說，這個指令沒有任何作用。
另外，當使用s-maxage 指令後，則直接忽略對Expires 首部欄位及max-age 指令的處理。
max-age指令
cache-extension token
Cache-Control: private, community="UCI"
通過 cache-extension 標記（token），可以擴展Cache-Control 首部欄位內的指令。
如上例，Cache-Control 首部欄位本身沒有community 這個指令。藉助extension tokens 實現了該指令的添加。如果緩存伺服器不能理community 這個新指令，就會直接忽略。因此，extension tokens 僅對能理解它的緩存伺服器來說是有意義的。
If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT
首部欄位If-Unmodified-Since 和首部欄位If-Modified-Since 的作用相反。它的作用的是告知伺服器，指定的請求資源只有在欄位值內指定的日期時間之後，未發生更新的情況下，才能處理請求。如果在指定日期時間後發生了更新，則以狀態碼412 Precondition Failed 作為響應返回。
ps:Last-Modified 存在一定問題，如果在伺服器上，一個資源被修改了，但其實際內容根本沒發生改變，會因為Last-Modified時間匹配不上而返回了整個實體給客戶端（即使客戶端緩存里有個一模一樣的資源）。
首部欄位If-None-Match 屬於附帶條件之一。它和首部欄位If-Match 作用相反。用於指定If-None-Match 欄位值的實體標記（ETag）值與請求資源的ETag 不一致時，它就告知伺服器處理該請求。
在GET 或HEAD 方法中使用首部欄位If-None-Match 可獲取最新的資源。因此，這與使用首部欄位If-Modified-Since 時有些類似。
不與伺服器確認，而是直接使用瀏覽器緩存的內容。其中響應內容和之前的響應內容一模一樣，例如其中的Date時間是上一次響應的時間。
F5的作用和直接在URI輸入欄中輸入然後回車是不一樣的，F5會讓瀏覽器無論如何都發一個HTTP Request給Server，即使先前的響應中有Expires頭部。
Ctrl+F5要的是徹底的從Server拿一份新的資源過來，所以不光要發送HTTP request給Server，而且這個請求裡面連If-Modified-Since/If-None-Match都沒有，這樣就逼著Server不能返回304，而是把整個資源原原本本地返回一份，這樣，Ctrl+F5引發的傳輸時間變長了，自然網頁Refresh的也慢一些。
Cache-Control 是 HTTP1.1 才有的，不適用於 HTTP1.0，而 Expires 既適用於 HTTP1.0，也適用於 HTTP1.1，所以說在大多數情況下同時發送這兩個頭會是一個更好的選擇，當客戶端兩種頭都能解析的時候，會優先使用 Cache-Control。
二者都是通過某個標識值來請求資源， 如果伺服器端的資源沒有變化，則自動返回 HTTP 304 （Not Changed）狀態碼，內容為空，這樣就節省了傳輸數據量。當資源變化後則返回新資源。從而保證不向客戶端重復發出資源，也保證當伺服器有變化時，客戶端能夠得到最新的資源。
其中Last-Modified使用文件最後修改作為文件標識值，它無法處理文件一秒內多次修改的情況，而且只要文件修改了哪怕文件實質內容沒有修改，也會重新返回資源內容；ETag作為「被請求變數的實體值」，其完全可以解決Last-Modified頭部的問題，但是其計算過程需要耗費伺服器資源。
Expires和Cache-Control都有一個問題就是服務端的修改，如果還在緩存時效里，那麼客戶端是不會去請求服務端資源的（非刷新），這就存在一個資源版本不符的問題，而強制刷新一定會發起HTTP請求並返回資源內容，無論該內容在這段時間內是否修改過；而Last-Modified和Etag每次請求資源都會發起請求，哪怕是很久都不會有修改的資源，都至少有一次請求響應的消耗。
對於所有可緩存資源，指定一個Expires或Cache-Control max-age以及一個Last-Modified或ETag至關重要。同時使用前者和後者可以很好的相互適應。
前者不需要每次都發起一次請求來校驗資源時效性，後者保證當資源未出現修改的時候不需要重新發送該資源。而在用戶的不同刷新頁面行為中，二者的結合也能很好的利用HTTP緩存控制特性，無論是在地址欄輸入URI然後輸入回車進行訪問，還是點擊刷新按鈕，瀏覽器都能充分利用緩存內容，避免進行不必要的請求與數據傳輸。
做法很簡單，就是把可能會更新的資源以版本形式發布，常用的方法是在文件名或參數帶上一串md5或時間標記符：
可以看到上面的例子中有不同的做法，有的在URI後面加上了md5參數，有的將md5值作為文件名的一部分，有的將資源放在特性版本的目錄中。
那麼在文件沒有變動的時候，瀏覽器不用發起請求直接可以使用緩存文件；而在文件有變化的時候，由於文件版本號的變更，導致文件名變化，請求的url變了，自然文件就更新了。這樣能確保客戶端能及時從伺服器收取到新修改的文件。通過這樣的處理，增長了靜態資源，特別是圖片資源的緩存時間，避免該資源很快過期，客戶端頻繁向服務端發起資源請求，伺服器再返回304響應的情況（有Last-Modified/Etag）。