ブラウザキャッシュによる HTTP 高速化チューニング
かれこれ一年ほど前に実施した実サービスでの apache のチューニングネタを思い出したように書いています。 以前いた部署では少ないサーバ台数で大量のリクエストを如何に処理しきるかってことに燃えていたので、静的コンテンツなどをブラウザに支障のない範囲で最大限にキャッシュさせ、サーバとネットワークの負荷を最小化させていました。 当時参考にした情報源は以下の３つでした。 どのようなレスポンスヘッダを返しておけばブラウザキャッシュを最大化できるかのテクニックがまとめられています。 ブラウザキャッシュとレスポンスヘッダ - murankの日記 Kazuho@Cybozu Labs: キャッシュの上手な使い方 [Studying HTTP] HTTP Status Code チューニングにおいて重要なのは自分自身での検証。というわけで自前で検証した結果と検証するために用意したプログラムを公開します。
Internet Explorer 9 において Webサーバーとの通信なしでキャッシュからコンテンツを表示する場合がある - Microsoft サポート
現象 Internet Explorer 9 で次の設定になっている場合、Web サーバーと通信せずキャッシュされたコンテンツを表示する場合があります。そのため、Web サーバーとの通信が必要な処理を行うことなくコンテンツが表示されることがあります。例えば、クライアント証明書を使った認証が必要なコンテンツ表示などがあります。 [インターネット一時ファイルと履歴の設定] で [自動的に確認する] が設定されている (既定値) 原因 本現象は Internet Explorer 9 の仕様です。 解決方法 この動作による Internet Explorer 9としての問題や影響はありませんが、以下のいずれかの方法で毎回 Web サーバーと通信してコンテンツを取得/表示させることができます。 Web サーバー側での対応 コンテンツのHTTP Header やMeta タグでCache-contr
Make IE cache the resources but always revalidate
The cache control header "no-cache, must-revalidate, private" allows browsers to cache the resource but forces a revalidate with conditional requests. This works as expected in FF, Safari, and Chrome. However, IE7+8 does not send a conditional request, that is, "If-Modified-Since" is missing in the request header and hence the server responds with HTTP/200 instead of HTTP/304. Here are the full se
IPA ISEC セキュア・プログラミング講座：Webアプリケーション編 第5章 暴露対策：プロキシキャッシュ対策
第5章 暴露対策 プロキシキャッシュ対策 プロキシキャッシュへのコンテンツ残留 ブラウザとWebサーバの間には、いくつかのキャッシュメカニズムが働いていることが多い。 プロキシサーバのキャッシュ──企業等LANを運用している多くの組織体ではLANからインターネットアクセスを行う際プロキシサーバを経由して行うことが多い キャッシュサーバ─インターネットプロバイダの中には、会員のWebアクセスを円滑にする目的でキャッシュサーバを運用しているところがある これらのキャッシュメカニズムは、ブラウザからのリクエストによって得られたコンテンツをキャッシュに保持しておき、同じURLのリクエストが生じたとき、本来のWebサーバにコンテンツを取りに行かず、キャッシュの内容をブラウザに渡すものである。 このようにキャッシュは、円滑なインターネットの利用に寄与してくれる。 しかし、コンテンツによっては、ただひと
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
