問題タブ [http-caching]

私の訪問者は、Varnish からページのキャッシュ バージョンを取得します。管理者ユーザーがページの現在のバージョンを常に表示できるようにしたいと考えています。このようにして、すべての変更が直接表示されます。

そのようなものは存在しますか？私は@never_cacheデコレータを知っています。ユーザーがログインしていない場合にのみ、そのようなものを探しています。

Django-CMS で動作する場合はボーナス ポイント!

私が REST 呼び出しを行うサーバーが Cookie を iPhone に渡すことを発見しました。また、HTTP Basic Auth も採用しています。

認証に使用するアカウントを変更できるアプリがありますが、didReceiveAuthenticationChallenge呼び出されることはないため、資格情報を変更しても問題ないことがわかりました。

私は2つの潜在的な修正を調べました：

• 資格情報が変更されるたびに手動で Cookie を削除する
• 設定[request setHTTPShouldHandleCookies:NO]

私はこれを正しく理解しているのだろうか。これでキャッシュが処理されると思っNSURLRequestReloadIgnoringCacheDataていましたが、そうではないようです。

どうすればこれを解決できますか?

編集:に設定しようとしましたshouldHandleCookiesがNO、Cookie がまだサーバーに渡されているようです。

Expiresとmax-ageの両方の表示を返すHTTP応答の場合、どちらが使用されますか？

それぞれが異なる時点を参照していることを考慮してください。

Cache-Control:no-storeとの実際的な違いはわかりませんCache-Control:no-cache。

私の知る限り、no-storeキャッシュデバイスがその応答をキャッシュすることを許可されていないことを意味します。一方、no-cacheは、最初にソースで検証せずに、キャッシュされた応答を提供できるキャッシュデバイスがないことを意味します。しかし、その検証は何についてですか？条件付き取得？

応答no-cacheにが含まれているが、含まれていない、またはない場合はどうなりますLast-ModifiedかETag？

よろしく。

私はこのヘッダーに混乱がCache-Control:must-revalidateあり、キャッシュされたアイテムを提供する前にソースですべてのリクエストを検証する義務があることを読みましたが、古いものだけですか？またはすべてが古くなっていても新鮮でも関係ありませんか？私は別の場所で両方のことを読みました。

との違いは何Cache-Control:no-cacheですか？これらのヘッダーは私と同じように見えるからです。

更新1：私は本からこれを読みました：

Cache-Control: must-revalidate応答ヘッダーは、鮮度計算メカニズムをバイパスし、すべてのアクセスで再検証するようにキャッシュに指示します。

@Peter O.は、RFCの内容を指摘しています。その古い本は間違っています。

更新2：このチュートリアルの内容：http ：//www.mnot.net/cache_docs/

no-cache—キャッシュされたコピーを解放する前に、キャッシュが検証のためにオリジンサーバーにリクエストを送信するように強制します。これは、認証が（パブリックと組み合わせて）尊重されることを保証するため、またはキャッシングのすべての利点を犠牲にすることなく、厳格な鮮度を維持するために役立ちます。

must-revalidate—表現について提供する鮮度情報に従わなければならないことをキャッシュに通知します。HTTPを使用すると、キャッシュは特別な条件下で古い表現を提供できます。このヘッダーを指定することで、ルールに厳密に従うようにキャッシュに指示します。

私はこのアクションメソッドを持っています：

そして、生成された応答は次のとおりです。

Varyヘッダーに代わりにアスタリスクが表示されるのはなぜAccept-Charsetですか？

OutputCacheAttribute応答に影響を与えますが、実際には、ヘッダーExpiresとCache-Control:max-age=nヘッダーはDuration引数に依存し、 Cache-Control:public//は引数に依存しprivateます。no-cacheLocation

OutputCacheAttribute何が起こっているかを確認するためのラッパーを作成しました。

ヘッダーは区切りに表示されていないので、おそらくOutputCacheAttributeconfigureが何をするのでしょうかHttpContext.Current.Response.Cache。

どのようfilterContext.HttpContext.Response.Cache.VaryByHeaders.UserCharSetにtrueであるか、たとえばfalsefilterContext.HttpContext.Response.Cache.VaryByHeaders.AcceptTypesであるかはわかりますが、ヘッダーには常に*と表示されます。Vary

可能な値は、のプロパティとしてリストされている4つの値だけfilterContext.HttpContext.Response.Cache.VaryByHeadersでしょうか？

乾杯。

私の知る限り、HTTPヘッダーVaryは、リクエストがキャッシュヒットかミスかを判断するときに、URLと一緒にキャッシュで考慮する必要があるHTTPヘッダーのコンマ区切りリストを指定します。

そのヘッダーが省略されている場合は、URLのみが考慮されることを意味します。

しかし、ヘッダーがである場合はどうなりVary:*ますか？

RFC 2616 14.4

***のVaryフィールド値は、要求ヘッダーに限定されない未指定のパラメーター（たとえば、クライアントのネットワークアドレス）が応答表現の選択に役割を果たすことを示します。*値はプロキシサーバーによって生成されてはなりません。オリジンサーバーによってのみ生成できます。

RFC 2616 13.6

*のVaryヘッダーフィールド値は常に一致せず、そのリソースに対する後続のリクエストは、オリジンサーバーによってのみ適切に解釈されます。

これは、このヘッダーを持つすべてのリクエストがキャッシュミスになることを意味しますか？

ASP.NETがHTTPヘッダーを使用すると、そのHTTPヘッダーが返されることがわかりました。ヘッダーがOutputCacheAttribute不要な場合、またはカスタムヘッダーを指定する場合は、その動作を明示的に無効にする必要があるため、（したい）信じています。ありそうもない。

の実用的な意味はどれVary:*ですか？

ありがとう。

フロントエンドのバックエンドとして RESTFul サービスを使用しています。サービスは、その応答に expires/etag/lastmodified ヘッダーを設定します。

私が探しているのは、サービスからデータをフェッチし、ehcache のようなプラグ可能なキャッシュ バックエンドにキャッシュできるクライアント側 (できれば Java) ライブラリです。

私ができるようにしたいことは、エントリが無効になるとすぐに、バックグラウンド ワーカー スレッドを使用してキャッシュを自動的に準備することです。また、条件付き GET を行うのは賢明なはずです。

私はhttp://hc.apache.org/httpcomponents-client-ga/tutorial/html/caching.htmlに出くわしました

誰かが知っている他のライブラリはありますか？これはかなり一般的な問題ではありませんか？

私は、プライマリ/唯一のコンシューマーがスマート/非Webブラウザークライアントになる新しいRESTフルAPIに取り組んでいます。クライアント自体ではなく、バックグラウンドプロセスによって維持/更新されるコレクションリソースがあります。最初の反復に必要な唯一のコンテンツタイプはJSONです。URIは次のようなものです。

• /items/-アイテムのコレクションを表すリソース。
• /items/123-IDを持つ個々のアイテムを表すリソース123。

クライアントは新しいアイテムを作成したり、コレクションを更新してアイテムを追加/削除したりすることはありませんが、個々のアイテムの値の一部を更新します。私の計画は、HTTP PATCHを使用して、独自のJSONパッチ形式を使用してアイテムリソースを更新することです。

多くの同時クライアントがアイテムを読み取り、異なるアイテムへの同時更新があり、同じアイテムへの同時更新が時折あります。ある程度の「結果整合性」は許可されますが、これを「キャッシュフレンドリー」として設計したいと思います。 「可能な限りの方法。PATCHのRFCを読むと、PATCHへの応答が成功すると、Request-URIのキャッシュが応答で更新される必要があることがわかります（応答がある場合）。問題は次のようになります。

私は：

/items/A）コレクションリソースのJSON表現に個々のアイテムの完全な表現を含め、PATCHを/items/URIに送信し、更新するアイテムをパッチ形式で含めますか？

長所：

• これにより、クライアントNはリソースのリストを表示するためだけに多くのリクエストを行う必要がなくなります。
• itemsクライアントがアイテムを更新するときに、のキャッシュを無効にします。

短所：

• 私は実際にコレクションを更新しているのではなく、個々のアイテムを更新しているので、これは私にとって「クリーン」ではありません。
• これにより、変更された単一のアイテムのキャッシュではなく、コレクション全体のキャッシュが無効になります。

また

B）リソースコレクションのJSON表現には、含まれているアイテムへのリンクのみを含め、コレクションに含まれているアイテムを検出した後、クライアントに個々のアイテムを要求させます。HTTP PATCHは個々のアイテムのURIに送信されます（例/items/123）

長所：

• コレクションとアイテムのリソースを個別にキャッシュします。個々のアイテムのPATCHは、そのアイテムだけのキャッシュを適切に無効にすることができます。
• 更新する特定のアイテムに対してHTTPPATCHを発行するため、APIはより明確になります。

短所：

• アイテムのバッチ更新は許可されません。これは現在のところまったく要件ではなく、将来的には予測していませんが、後知恵は20〜20です。
• N+1アイテムの完全なリストを表示する要求を発行するようにクライアントに要求します。

こんにちは、フォームと多くの入力を含むテンプレートがあり、ビューへの POST リクエストを介してデータを渡し、それらを処理して結果を別のテンプレートに送信します。最終的なテンプレートで、ブラウザの戻るボタンを使用して最初のビューにジャンプすると、古いデータが再び表示されます。ページを更新すると、古いデータがフラッシュされ、新しいデータが挿入され、再度送信されますが、最終的なビューを見ると古いデータが残っています。デバッグサーバーを再起動しても問題は残ります。ブラウザのキャッシュをフラッシュするだけで解決できる（場合によっては解決できない）データキャッシングの問題があるようです。これはビュー コードです: http://dpaste.com/643569/と最初のテンプレート コード: http://dpaste.com/640960/. ここstackoverflow.comの誰かが、それを制御する「キャッシュナビゲーター」であると言い、カスタムミドルウェアを使用して無効にすることを提案したので、そのアドバイスに従いました：

my_app/util にファイル middleware.py を作成し、それを settings.py のミドルウェア セクションに挿入しました。また、html の head セクションに pragma no cache meta tag を追加しましたが、どれも役に立ちませんでした。問題は残ります。

助言がありますか？