web-dev-qa-db-ja.com

HTTP 304 Not Modified-responsesにcache-controlヘッダーを含める必要がありますか？

私はこれを理解しようとしました、そして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応答にキャッシュ制御ヘッダーを添付することになっていますか？仕様で読み取ることができるものから、キャッシュ制御設定は省略されるべきであり、キャッシュはそれを120秒間自動的にキャッシュする必要がありますか？

htmlhttp-headersetag
55
runarM

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

したがって、実際には、同じCache-Controlを200の場合と同じ304に含める必要があります。仕様では、以前に送信したものと異なる場合にのみ、304に送信するように指示しています（ 10.3.5を参照）。 304変更されていません ）-ですが、それが同じである場合、それを繰り返すことを禁止するものではありません。

そして、他の答え（構造）の間違ったポイントに具体的に応答するには：

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

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

39
Justin Ludwig

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

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

46
Mark Nottingham

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

このリクエストを受信すると、サーバーは200 OK、304 Not Modified（または必要に応じて4XX）で応答します。

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

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

少し良く読めるように最初の段落を編集しました（うまくいけば）

2
Structure