Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。SierraにHomebrewでapache2を入れ、png画像とhtmlを配置しています。画像をキャッシュしたいと思い、以下のようにhttpd.confの設定をしました。強制的にdiskキャッシュするためのモジュールのインポートと、diskキャッシュの設定と、ヘッダの設定です。Last-modefiedとExpireがレスポンスヘッダに乗っていないとキャッシュされないと(どこかで)見たためこちらも追記しており、両方正常にレスポンスヘッダに乗っていることを確認しています。cache)と表示されていることを確認しているのですが/tmp/cacheには何もファイルが残っていません。chromeを再起動してから再び画像にアクセスするとStatus200となります。Webサーバの設定でブラウザを再起動してもローカルのキャッシュを表示する方法はありますか?1回目のアクセス時のレスポンスヘッダです。↓ご指摘頂き、apacheの設定の仕方が間違っていたことがわかりました。max-age=86400"とすることでChromeを再起動させてもapacheにアクセスログが表示されないことを確認しました。safariではアクセスがされてしまい、固有のバグのようでした。ローカルキャッシュの活用を考えていますが、やりたいこととしては必要のない画像取得の通信を出来るだけ減らしたい、更新のない同じ画像を何度もapacheからダウンロードさせるのは避けたいが更新があれば通信させるということです。オフラインでも動くことは求めておらず、画像はバナーや商品画像など様々なものがあるためマニフェストファイルに画像を指定するApplicationCacheよりローカルストレージを使い、キャッシュを更新したいときはAPIから更新フラグを受け取り、更新する場合はclearCacheするという方法を用いたいと思います。↓と思ったのですがAPIからキャッシュクリアするフラグを入れるのは悪手だということがわかりました。どれだけの期間フラグをtrueにするかの問題とか、フラグがtrueになっている間はアプリを起動するたびにキャッシュ削除→画像再取得という状態になってしまうので、画像URLを変更しようと思います。どこで何をキャッシュさせたいのか考え直すことをお勧めします。23:52実際に尋ねたい内容に沿うよう、質問文を修正してください。現状ではmod_cacheもあまり関係なさそうに感じます。23:55質問文を変更しました。sayuriさんが仰ってますが、サーバキャッシュを設定してキャッシュを確認するのにクライアント側で確認できないかと思います。クライアント側のブラウザにキャッシュさせたいのであれば別の方法を用いるべきです。票3サーバーサイドキャッシュとクライアントサイドキャッシュは別物です。それぞれ区別して考える必要があります。一度指摘しましたが、修正してもなお「サーバーサイドキャッシュの設定を行ったがクライアントサイドキャッシュが行われていない」旨が質問されていて、質問者さん自身が何を求めているのかわかっていない印象を受けます。質問文からはディスクの別領域に置かれている画像ファイルをこのディレクトリ下にコピーされることを期待しているように読み取れますが、コピーする意義がありません。gzipなどで圧縮されたコンテンツが置かれる場所と考えるべきです。(IISは後者も置いていましたがApacheは置かなかったような...うろ覚えです。)次にクライアントサイドキャッシュについてですが、設定内容だけでなくブラウザー側で受信したレスポンスヘッダーも提示していただかないことにはわかりません。レスポンスヘッダーとは全く別アプローチのアプリケーションキャッシュという機構もあります。こちらも一つの選択肢としてお考え下さい。GMT"のヘッダーが含まれていません。設定内容が正しく反映できているかを確認すべきですし、それができていなければあらゆる設定に意味を持たないと思います。アプリケーションキャッシュはサ‌​ーバ側で更新することが難しい(間違った画‌​像を配信した場合にすぐ更新するのが難しい‌​)と聞いてローカルストレージを優先して試‌​そうと考えていますそもそもWebサーバーと通信しないようにしたいという質問だったはずです。通信しない以上、どのような方法であれWebサーバー側での更新内容を知ることはできません。最初に指摘しましたが、どこで何をキャッシュさせたいのか考え直すことをお勧めします。個の銅バッジすみません、コメントが途中で送信されました。1:56受信箱にお知らせが出ず、お返事が遅くなり申し訳ありません。ありがとうございます!ヘッダの書き方が間違っていました。appendではなくsetにしたらChrome再起動後もキャッシュ出来ることが確認できました。safari固有のバグのようです。何をキャッシュさせたいかについては、これからじっくり考えてみようと思います。何度もおつきあい頂きありがとうございました。設定できるモジュールです。次の記述でPNG画像に対してキャッシュ期限が「アクセスから1ヶ月」となるヘッダが出力されるはずです。mod_expires.c>このように長いExpiresを指定した場合キャッシュの破棄をどうするかですが、よく使われる方法として、画像の更新時は画像のURLを変更する、というものがあります。ファイル名を変えてもいいですし、クエリ文字列にタイムスタンプやハッシュ値を埋め込んでもよいです。foo.png?v=20170308こうすれば更新前とは違うURLなので、既存のキャッシュが使われることはありません。使われることもありません。完全に通信をなくすことはできませんが。これは非同期APIを持たないので、保存・取り出しのどちらもUIスレッドをブロックします。格納できるデータの量も5MB程度とさほど多くありません。IndexedDBならいくぶんマシですが...。Rocksキャッシュ絡みの問題でよく使われる「ブラウザのキャッシュ削除機能」「スーパーリロード」が使えない、ユーザー側のストレージでキャッシュ用でない領域を消費する、といった細かい話も。キャッシュ機能なら、JavaScriptを使って柔軟に制御することができます。こちらはブラウザの対応状況が芳しくないです。If-**)では不十分なのかを検討された方がいいように思います。個の銅バッジ参考URLを読むのに時間がかかりお返事が遅くなりすみません。手動の日付指定については、mod_expiresが実際に効いてるかよくわからなかったため固定の日付を入れてヘッダの確認を‌​していました。Expiresが効いている‌​間は更新確認が行われないとは知りませんで‌​した。両方指定しても意味が無いのですね。‌​If-None-Matchについては、ス‌​テータス304でもEtagの比較が重いの‌​か、Androidで結構重い現象が起きて‌​おり、出来ればキャッシュを使いたいと思っ‌​ております。ローカルストレージのデメリットについて、詳しい記事のご紹介ありがとうございます。二回目以降のアクセスはかなり快適になって‌​おり、取り出しに関してはあまりブロックさ‌​れたというほど不快な操作感がないのですが‌​、認識しておきます。キャッシュ対象である画像の容量は最大でも800kほどなので、アンドロイドで2MB、iOSで5MBあれば大丈夫だと思います‌​が、画像作成の際の知識として覚えておきま‌​す。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。