3

Jetty で実行されている Jersey で実装された REST Java サーバーがあります。特定のブラウザー (IE7) は、サーバーに対して行われたすべての要求を内部的にキャッシュしているようです。

私がやりたいことは、REST サーバーからの応答で特定の HTTP ヘッダーを送信して、その応答をキャッシュしてはならないことをブラウザーに示し、次にそのリソースへのアクセスが必要になったときにサーバーに再度クエリを実行することです。

このためにJersey/Jettyを構成する方法についてのアイデアはありますか? または、それを構成する唯一の方法はクライアント側ですか?

4

4 に答える 4

3

response.setHeader("プラグマ", "キャッシュなし");

ダメダメダメ！

クライアント側のキャッシュを無効にするプラグマ ヘッダーの使用は間違っています。これは要求ヘッダーであり、応答にはまったく影響しません。

http://www.mnot.net/cache_docs/#PRAGMA

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32

また、Expires: 0 の設定は正しくありません。Expires は秒数ではなく日付である必要がありますが、無効な http 日付は「すでに期限切れ」と解釈されるため、これは機能します。

http://www.mnot.net/cache_docs/#EXPIRES

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.21

于 2008-10-04T03:24:52.563 に答える
2

不正なクライアントについてできることは何もありませんが、Jettyは適切なHTTPヘッダーを送信できます。Last-ModifiedヘッダーとCache-Controlヘッダーの構成については、こちらをお試しください。

于 2008-09-24T15:04:09.427 に答える
2

サーバー側では、応答にアクセスできる場合にこれを試すことができます（フィルターを介して実行できる場合があります）。

response.setHeader("Pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Expires", "0");

クライアント側で試すことができるもう1つのトリックは、「http://www.company.com/services/staff?id=xxx&requestTime=」+(newDate()).getTime()のような余分な引数をURLに追加することです。 ; このように、リクエストされているURLは毎回異なり、キャッシュすることはできません。

于 2008-09-24T15:05:53.263 に答える
0

@Dave Cheney: まあ、 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9から私が理解しているのは、キャッシュ制御がリクエストとレスポンスに対して意味があるということです。また、応答がキャッシュ制御の応答である場合、それはクライアント (ブラウザー) がリソースに対して行うべきことの仕様です (次のセクション 14.9.1 を参照)。

@all: また、同じドキュメントのセクション 14.21 で、0 に設定された Expires ヘッダーは「無効な日付」を意味し、クライアントは無視できると指定されています。そして、有効期限を 1970 年 1 月 1 日 (タイムスタンプ 0) に送信する私のテストでは、IE から無視されるだけで (さらには ff)、応答がキャッシュされます。

私の解決策は、仕様に記載されている Expires フィールドの現在の日付を送信することでした。

于 2010-02-02T14:58:11.803 に答える