56

私はこれを理解しようとし、SOで同様の質問を検索しましたが、これがどのように機能するかについてはまだ100％理解していません。

画像リソースのリクエストで次の応答があります。

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:04:04 GMT
    Expires Mon, 19 Oct 2009 09:06:05 GMT
    Cache-Control   public, max-age=120
    Etag    image_a70703fb393a60b6da346c112715a0abd54a3236
    Content-Disposition inline;filename="binary-216-420"
    Content-Type    image/jpg;charset=UTF-8
    Content-Length  4719

望ましい動作は、クライアントがこれを120秒間キャッシュしてから、サーバーに再度要求することです。120秒以内に、サーバーに要求は送信されません。

次に、120秒後、要求が送信され、304応答が受信されます。

Response Headers
    Server  Apache-Coyote/1.1
    Date    Mon, 19 Oct 2009 09:06:13 GMT

Request Headers
    Host    localhost:8080
    User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
    Accept  image/png,image/*;q=0.8,*/*;q=0.5
    Accept-Language en-us,no;q=0.8,sq;q=0.7,en;q=0.5,sv;q=0.3,nn;q=0.2
    Accept-Encoding gzip,deflate
    Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
    Keep-Alive  300
    Connection  keep-alive
    Referer http://localhost:8080/cms/site/0/en/home
    Cookie  JSESSIONID=768ABBE1A3BFABE3B535900233330650; versionsCssDisplayState=block; iceInfo=iceOn:false,activePortletKey:,icePagePanelX:1722,icePagePanelY:3
    If-None-Match   image_a70703fb393a60b6da346c112715a0abd54a3236

これまでのところ、すべて順調です。しかし、次のリクエスト（120秒以内）で、リソースを新しい120秒間キャッシュする必要があると思いました。一方、ブラウザ（Firefox）に表示されるのは、この時点から常にリソースを要求し、304応答を受信することです。

304応答でcache-controlヘッダーを添付することになっていますか？仕様で読み取れることから、キャッシュ制御設定を省略し、キャッシュが自動的に120秒間キャッシュする必要があるようです。

4

3 に答える 3

49

RFC7232は RFC2616 を次のように更新します。

304 応答を生成するサーバーは、同じ要求に対する 200 (OK) 応答で送信される次のヘッダー フィールドのいずれかを生成する必要があります: Cache-Control、Content-Location、Date、ETag、Expires、および Vary。

于 2010-12-08T23:45:42.647 に答える
41

理論的には、304 に対して Cache-Control を送信する必要はありません。受信者は、元の 200 から受け取ったキャッシュ ディレクティブを引き続き使用する必要があります。 Cache-Control を送信し続けると、ブラウザーは最初に送信したキャッシュ ディレクティブを無視し、独自の既定のヒューリスティックに戻ります。

したがって、実際には、200 を使用する場合と同じ Cache-Control を 304 に含める必要があります。仕様では、以前に送信したものと異なる場合にのみ、304 に対して送信することを義務付けています ( 10.3.5 304 Not Modifiedを参照) 。 --しかし、同じものを繰り返すことを禁じているわけではありません。

そして、他の回答（構造の）からの間違った点に具体的に対応するには：

  1. 中間キャッシュで応答をキャッシュする (つまり、リソースのキャッシュ エントリを更新する) 必要があります。クライアントが If-Modified-Since のような条件付きヘッダーを含んでいるかどうかに応じて、クライアントからの要求に 200 または 304 で適切に応答します。

  2. 120 秒の ttlは304 によって更新されます (したがって、同じクライアントは、少なくともさらに 120 秒間、同じリソースに対して別の要求を行うべきではありません)。また、クライアントは、コンテンツがキャッシュされている限り、リソースに対して条件付きの要求を出し続けます。これには 304 で応答し続けることができます。

于 2009-12-23T22:19:22.430 に答える
2

私が正しく理解していれば、ブラウザは実際には120秒間キャッシュしており、サーバーは後続のIf-Modified-Sinceリクエストに対して304NotModifiedに応答しています。この「IMS」リクエストは、エンドユーザーが同じURLにアクセスしたときに発生します。その時点で、ブラウザはIf-Modified-Sinceリクエストを送信できます。ブラウザは、古いコンテンツを表示しているかどうかを知りたいと考えています。これは正常のようです。

この要求を受信すると、サーバーは200 OK、304 Not Modified（または必要に応じて4XX）と応答する必要があります。

次の2つの理由から、304応答を含むCache-Controlヘッダーを送信するようにサーバーを設定する必要はないと思います
。1。中間キャッシュに304応答をキャッシュさせたくない（可能性がある）
2。 120秒のTTLは、304応答によって更新されません。ブラウザは、200OK応答から120秒間オブジェクトを保持します。120秒後、ブラウザはIf-Modified-SinceではなくGETリクエストを送信する必要があるため、サーバーは304応答だけでなく、ファイルのバイトで応答します。

エンドユーザーがページの読み込みまたはアドレスバーにURLを直接入力することで特にファイルを要求しない限り（またはその機能を何らかの方法で制御するカスタムアプリケーションがない限り）、ブラウザは120秒後にファイルを自動的に要求しないことに注意してください。

最初の段落を編集して少し読みやすくしました（うまくいけば）

于 2009-10-19T10:13:30.820 に答える