クラシックASP-IIS 5からIIS 6への移行により画像キャッシュの問題が発生しますか？

Question

長文の質問にはおAび申し上げます。

私は実際にデータベースプログラマですが、最近IIS 5からIIS 6を実行する新しいサーバーに移行されたクラシックASPイントラネットアプリケーションのサポートを受け継ぎました。 6。

UIは、データベースから返されたアイテムの階層を表示します。ユーザーがナビゲートすると、HTML順不同リストとJavaScriptの組み合わせを使用してブランチを非表示/展開します。

CSSを使用してリストのメンバーの横に画像が表示され（list-style-imageを使用）、アイテムのタイプごとに異なる画像が使用されます。階層内の異なるアイテムタイプ（したがって画像）の数は2〜10の間で変化します。階層は20〜200アイテムの間で変化します。

問題：

IIS 6への移行以来、複数のユーザーが、階層内の1つ以上のアイテムに適切に適用されていないイメージが原因であると思われる問題を経験しています。リストは正しく表示されますが、1つ以上の画像が欠落しており、リンクをクリックすると空のページが読み込まれます。

WiresharkとIISログを使用したネットワークトラフィックの分析では、問題はサーバー側ではなく、すべてのコンテンツがクライアントに正しく提供されていることがわかります。

この問題は、クライアントでのコンテンツキャッシングに関連しているようです。現在のPCで以前にアプリケーションを使用したことがないか、しばらく使用していないユーザーに影響を与えることが多いようです。 また、セッションを開始し、ブラウザーのキャッシュをクリアしてからページを更新することで、3回に1回程度で問題を再現できます。ただし、IIS 5で実行しているアプリケーションでも同じことが当てはまるため、この問題はIIS 6への移行前に存在していた可能性がありますが、発生頻度は低くなっています。 時折、20分ほどセッションを離れると、ブラウザは「検索」するように見えます。不足している画像、およびすべてが正常に動作します。

アプリケーションがローカルプロキシ（私はFiddlerを使用）を介してアクセスされた場合、Fiddler接続ログには、イメージを取得するためにサーバーに対して行われた1つ以上の接続が中止されますが、問題は発生しません。前と同様に、ネットワークトラフィックは、サーバーからイメージが返されたことを示しています。ただし、プロキシを使用すると、IEはキャッシュから他の正常に取得された画像のコピーを見つけることができるようです。

ASP / IISの問題のデバッグに関する限られた知識の終わりに到達しました。 CSSからlist-style-imagesを削除すると問題は解決しますが、アプリケーションの使用がより難しくなるため、これは最後の手段のオプションである必要があります。

今後の進め方についての提案はありがたいことに受け取られます。

編集

AnonJrは、他のすべてのコンポーネントが正しく機能しているように見えるため、これはクライアント構成の問題でなければならないことを示唆しています。

これは、説明されている問題の影響を受ける唯一のアプリケーションであるため、単純なクライアント構成の問題を無視しました [ツール]＆gt;ですべてのオプションをテストしました。インターネットオプション＆gt;一時ファイル＆gt;動作に変更のない設定。

他にどのようなクライアント設定オプションを検討すべきですか？

編集2-ソリューション

受け入れられた回答により、クライアント側スクリプトからHTMLが生成されたときに、IE6が画像の複数のコピーを要求するという既知の問題を検索するように促されました- http://support.microsoft.com/default.aspx?scid=kb;en-us;319546 。

（この動作は「設計による」と述べている）記事では、必要な画像を非表示のDIVにロードして事前キャッシュする回避策を提案しています。

<DIV style='display:none'><IMG SRC='image.gif'></DIV>

これは私にはうまくいくようです-セッションの途中でブラウザのキャッシュをクリアしても問題を再現できなくなり、Fiddlerトレースに各画像が表示されます

Answer 1

これは、ブラウザが同じリソースに対して複数のリクエストを行うIE6バグのスマックです。たとえば、コンテンツがリスト内で20回繰り返される小さなアイコンの表示を要求する場合、そのイメージを1回取得するだけでなく、20回取得しようとします。 OK応答のうち19は304 Not Modifiedですが、それでもサーバーへの19の余分なラウンドトリップです。

過去にこの過剰なリクエストを発見しましたが、最終的には未充足のリクエストが多すぎます。その時点で、少なくともしばらくの間、他のページが応答を取得するのに苦労している場合でも、サーバーへの要求はさらに増えます。

これがあなたのケースで起こっているかどうかわかりません。これを調べる1つの方法は、代わりにIE7を使用して同じ問題が発生するかどうかを確認することです。このバグはIE7で修正されました。

編集：問題がバグであることが確認されたので、「短い時間の遅れ」へのKBの参照にも注意してください。根本的な問題は、新しくフェッチされたイメージを再利用するために、ブラウザーが、javascriptの現在のチャンクが完了するまで延期される作業を行う必要があることです。 「短い時間遅延」以上が必要であり、非同期アプローチが必要です。

display：none DIVアプローチを使用して画像をプリフェッチしましたが、これはAJAXスタイルの作業に適しています。ただし、ウィンドウのonloadイベントの実行中または実行前にコードを実行している場合、このコードに画像を追加するときに問題が発生します。 onloadイベントの完了後にさらにコードを実行するには、setTimeoutが必要です。

Answer 2

クライアントエンドのキャッシュ設定の調整に注意を集中することができます。サーバーから画像が送信されている場合、IISの問題ではない可能性があります。画像のHTMLがブラウザに送信されている場合、ASPの問題ではありません。これでクライアントは残ります。

プロキシはいくつかの問題を緩和している可能性があり、および/またはIE6が画像などをキャッシュする方法を決定する要因になる可能性があります