10

GWTを使用してWebアプリを開発していapp.nocache.jsますが、Webサーバーがファイルの新しいコピーを送信したにもかかわらず、ブラウザーでのファイルのキャッシュに問題が発生しています。

私はEclipseを使用してアプリをコンパイルしています。これは開発モードで動作します。本番モードをテストするために、ホストマシン（Windows 7）で実行されているUbuntuゲストOSを備えた仮想マシン（Oracle VirtualBox）があります。VMでlighttpdWebサーバーを実行しています。VMは私のプロジェクトのwarディレクトリを共有しており、Webサーバーはこのディレクトリを提供しています。

ブラウザとしてChromeを使用していますが、Firefoxでも同じことが起こります。

シナリオは次のとおりです。

  • アプリのウェブページが空白です。Chromeの「要素の検査」ツールによると6E89D5C912DD8F3F806083C8AA626B83.cache.html、これは、存在しないフェッチを試行しているためです（404 not found）。
  • warディレクトリを確認しましたが、そのファイルは存在しません。
  • サーバー上のファイルがブラウザのキャッシュよりも新しいため、app.nocache.jsブラウザ上のはWebサーバーからリロードされました（200 OK）。サーバーから返された新しいファイルのファイルサイズとタイムスタンプが正しいことを確認しました。（これは、ChromeがサーバーのHTTP応答について報告する情報です）

  • ただし、app.nocache.jsブラウザでを開くと、javascriptは6E89D5C912DD8F3F806083C8AA626B83.cache.html!!!を参照しています。つまり、Webサーバーが新しいを送信したとしてもapp.nocache.js、ブラウザはそれを無視し、キャッシュされたコピーを使用し続けたようです。

  • Google->EclipseでのGWTコンパイルに移動します。すべてを再コンパイルします。

  • warディレクトリで、app.nocache.jsが上書きされ、新しいタイムスタンプがあることを確認します。
  • Chromeからページを再読み込みし、サーバーがに200OK応答を送信したことをもう一度確認しますapp.nocache.js。
  • ブラウザはもう一度ロード6E89D5C912DD8F3F806083C8AA626B83.cache.htmlを試みて失敗します。ブラウザはまだの古いキャッシュコピーを使用していますapp.nocache.js。
  • 戦争ディレクトリで、何も参照していないことを絶対に確認しました6E89D5C912DD8F3F806083C8AA626B83.cache.html（findとgrepを介して）

何が問題になっていますか？サーバーが新しいコピーを送信している場合でも、ブラウザがこのnocache.jsファイルをキャッシュするのはなぜですか？

これは、ブラウザで[再読み込み]をクリックしたときのHTTP要求/応答ヘッダーのコピーです。このトレースでは、最後のGET以降、サーバーコンテンツは再コンパイルされていません（ただし、キャッシュされたバージョンのnocache.jsはまだ間違っていることに注意してください）。

Request URL:http://192.168.2.4/xbts_ui/xbts_ui.nocache.js
Request Method:GET
Status Code:304 Not Modified
Request Headersview source
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Host:192.168.2.4
If-Modified-Since:Thu, 25 Oct 2012 17:55:26 GMT
If-None-Match:"2881105249"
Referer:http://192.168.2.4/XBTS_ui.html
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/22.0.1229.94 Safari/537.4
Response Headersview source
Accept-Ranges:bytes
Content-Type:text/javascript
Date:Thu, 25 Oct 2012 20:27:55 GMT
ETag:"2881105249"
Last-Modified:Thu, 25 Oct 2012 17:55:26 GMT
Server:lighttpd/1.4.31
4

6 に答える 6

5

ブラウザのキャッシュを回避する最善の方法は、有効期限をnowに設定し、max-age=0とmust-revalidateコントロールを追加することです。

これは私がapacheで使用する構成です-httpd

ExpiresActive on
<LocationMatch "nocache">
   ExpiresDefault "now"
   Header set Cache-Control "public, max-age=0, must-revalidate"
</LocationMatch>
<LocationMatch "\.cache\.">
   ExpiresDefault "now plus 1 year"
</LocationMatch>

lighthttpdの設定は次のようになります。

server.modules = (
    "mod_expire",
    "mod_setenv",
)
...
$HTTP["url"] =~ "\.nocache\." {
  setenv.add-response-header = ( "Cache-Control" => "public, max-age=0, must-revalidate" )
  expire.url = ( "" => "access plus 0 days" )
}

$HTTP["url"] =~ "\.cache\." {
  expire.url = ( "" => "access plus 1 years" )
}
于 2012-10-26T07:02:50.470 に答える
5

同様の問題がありました。nocache.jsのタイムスタンプがgwtcompileで更新されていないことがわかったため、ビルド時にファイルにアクセスする必要がありました。そして、@ManoloCarrascoMoñinoからの修正も適用しました。この問題についてブログを書きました。http://programtalk.com/java/gwt-nocachejs-cached-by-browser/

コメントでも指摘されているように、バージョン2.7のGWTを使用しています。

于 2015-11-13T10:17:23.643 に答える
3

2つの簡単な解決策があります（2番目は最初のものの修正バージョンですが）

1）*.nocache.jsへの参照を持つ*.htmlファイルの名前をMyProject.htmlからMyProject.jspに変更します。次に、MyProject.htmlで*.nocache.jsスクリプトの場所を検索します。

<script language="javascript" src="MyProject/MyProject.nocache.js"></script>

JSファイルのパラメーターとして動的変数を追加します。これにより、実際のコンテンツが毎回サーバーから返されるようになります。以下は例です

<script language="javascript" src="MyProject/MyProject.nocache.jsp?dummyParam=<%= "" + new java.util.Date().getTime() %>"></script>

説明：dummyParamは役に立ちませんが、意図した結果が得られます。つまり、304ではなく200のコードが返されます。

注：この手法を使用する場合は、アプリケーションをロードするために正しいjspファイルを指していることを確認する必要があります（この変更の前は、HTMLファイルを使用してアプリをロードしていました）。

2）JSPソリューションを使用せず、htmlファイルを使い続けたい場合は、nocacheファイルをロードするときにクライアント側で一意のパラメーター値を動的に追加するJavaスクリプトが必要になります。上記の解決策を考えれば、それは今では大したことではないと思います。

私は最初のテクニックをうまく使いました、これが役立つことを願っています。

于 2014-01-15T16:34:16.693 に答える
2
  • サーバー上のファイルがブラウザーのキャッシュよりも新しいため、ブラウザー上のapp.nocache.jsがWebサーバーからリロードされました（200 OK）。サーバーから返された新しいファイルのファイルサイズとタイムスタンプが正しいことを確認しました。（これは、ChromeがサーバーのHTTP応答について報告する情報です）

私はこれに頼りません。Chromeの開発ツールで[ネットワーク]タブとキャッシュを組み合わせた奇妙な動作を少し見ました（少なくとも、100％透過的ではありません）。疑わしい場合は、私は通常、Firebugに相談します。

したがって、おそらくChromeはまだ古いバージョンを使用しています。ずっと前に、リソースを再度リロードする必要がないことを決定した可能性があります。キャッシュをクリアすると、これが解決するはずです。次に、ページをリロードする前に、正しいキャッシュヘッダーを設定してください。たとえば、さまざまなタイプのリソースの理想的なHTTPキャッシュ制御ヘッダーを参照してください。

于 2012-10-25T23:53:17.997 に答える
0

キャッシュの問題を取り除き、自分のブロックを解除するためだけに、ページをコグニートモードで開きます。

他のコメントで述べられているように、キャッシュ時間を設定する必要があります。

于 2017-07-05T03:24:18.877 に答える
-1

Apacheを介したキャッシュの防止に失敗した後、LinuxTomcatサーバーのcronジョブでrootが毎分実行されるbashスクリプトを作成しました。

#!/bin/bash
#
# Touches GWT nocache.js files in the Tomcat web app directory to prevent caching.
# Execute this script every minute in a root cron job.
#
cd /var/lib/tomcat7/webapps
find . -name '*nocache.js' | while read file; do
    logger "Touching file '$file'"
    touch "$file"
done
于 2014-07-04T00:13:59.693 に答える