IE 8のメモリページを削除しますか？

Question

この質問は、this questionのスピンオフ/進化です。 （私はそれに恩恵をかけ、それは自動的に解決されたので解決されたとマークされていますが、実際には答えられませんでした）。

概要は次のとおりです。クライアントが奇妙なURLを要求するとエラーが表示されることがあります。クライアントが要求しているリソースから、htmlソースから4KBのテキストが欠落しているように見えます。

簡単な例

...私たちはこのようになりますページがある場合： "myValidLiORE％の20STUFFの％の20LATER"：

<a href="myValidLink.aspx">Here's some text</a> 
a bunch more stuff 
...(a large block of text)... 
AND NOW MORE STUFF LATER 

クライアントがURLを求めることができるが。

htmlソースのセクションが存在しないように振る舞い、欠落しているセクションは正確に4KB（4096バイト）（または人によっては1KBになることもあります）のようです。

残念ながら、このエラーは要求に応じて複製することはできませんが、1日に何回もクライアントから送信されます。

これはWebresource.axdの問題であると私たちは考えました。なぜなら、私たちはそれがたくさんあることを知ったからです...しかし、これは主に、類似のエラーをまとめてグループ化していたためです。その特定の地域で腐敗が発生したとき。私はより広い範囲の問題を見ているので、チャンクを外す同じ問題によって引き起こされているように、非常に異なるエラーが発生している場所を見ています。

私たちはこれをIE 8で多く見てきましたが、IE 8が普及してきたため、これが頻繁になりました。私たちは時折、IE 7として自分自身を報告するブラウザを参照しています... IE 8は「互換モード」に入っていればそれを行います。

私の理論は、この時点（テストする方法を見つけようとしています）は、Webサーバーがバイトストリーム内のすべてのデータを正しく送信しているということです。IE 8問題があり、いくつかの条件の下でメモリページ（4k）をドロップします。

しかし、私はこの理論を少しは心配しています。明らかに、IE 6やFF 3でこれを "時折"見ている人がいます。これらはアウトライヤになる傾向があり、同様の問題しかし、それが本当にそれらのブラウザー上で同じものであれば、それは私の理論を水から吹き飛ばすだろう。それでも、私は今のところ良いアイデアはありません。

私が持っていたもう1つのアイデアは、おそらくサーバ上の比較的最近のサービスパックが、データをクライアントに提供する際に問題を引き起こし、時折4KBをドロップするということです。この理論の問題は、IE 8でのエラーの大きな優位性と他のクライアントブラウザでのエラーの欠如を説明していないことです。

だから、うまくいけば、最終的に答えを持っています質問：

1. は、誰がこれを検出しましたか？ （おそらくそれはあなたのレーダー上にあるでしょうか？）
2. 誰でもこの問題を一貫して複製できますか？
3. それは何ですか？あなたは私の理論を確認したり、反論することはできますか？
4. 修正または回避策はありますか？

Answer 1

**編集4/1/10：** 更新：4kバグは、2010年3月30日のIE8累積更新で修正されるようになりました。 blogs.msdn.com/ieinternals/archive/2010/04/01/

Internet Explorerチームがこの問題を調査しています。

- = =インパクト -

はこれまで、我々は問題がWebアプリケーションとエンドユーザーの体験に影響を及ぼさないと考えています。唯一の悪影響は、JavaScript投機ダウンロードエンジンによって送信された擬似/不正なリクエストです。スクリプトがパーサーによって実際に必要とされるとき、それは適切にダウンロードされ、その時に使用されます。

- =事情= -

スプリアス要求は、事前にパーサを再起動するように強制された場合にのみ、唯一の特定のタイミング状況で発生するように見える（コンテンツタイプを含む場合META HTTP-EQUIVタグとしてドキュメント内にCHARSETディレクティブが表示されます）、JavaScript SRC URLがHTTP応答本体の4096バイトにまたがる場合のみです。

- =回避策= -

現在、この問題は、一般的にHTTPのContent-Typeヘッダを使用してページのCHARSETを宣言するのではなく、ページ内に指定することによって緩和することができると信じています。あなたの頭のタグで

、代わりに、送信;

だから、むしろ

置くより[META HTTP-EQUIV = "Content-Typeの" CONTENT = "文字セット= UTF-8テキスト/ HTMLを"]次のHTTP応答ヘッダー：

コンテンツタイプ：text/html; charset = utf-8

HTTPヘッダーの文字セットを指定すると、すべてのブラウザーでパフォーマンスが向上することに注意してください。ブラウザーのパーサーは、文字セット宣言に遭遇してから最初から解析を再開する必要がないためです。さらに、HTTPヘッダーを使用すると、特定のXSS攻撃経路を緩和できます。

Answer 2

http://blogs.msdn.com/ieinternals/archive/2009/07/27/Bugs-in-the-IE8-Lookahead-Downloader.aspxは、この問題の最新の投稿です。

欠落している4 KBバグ： この記事では、「ページ内で指定するのではなく、HTTP Content-Typeヘッダーを使用してページのCHARSETを宣言することで、パーサーの再起動の原因を1つ削除できます。 Eric Lawrenceの電子メール： "残念ながら、パーサーを再起動するもう1つの原因は、サイトが使用していると思われるXML名前空間の使用です。したがって、XHTMLを使用すると、4Kの問題が発生する可能性があります。

Answer 3

同じ問題があります。私は追加しています：

私たちのベースページのクラスに。私はすぐに結果を報告します。

Answer 4

FWIW LogParserのログの1ヶ月間の統計です。ユーザーエージェント情報別で

12331 hits to ScriptResource & WebResource/183 errors

。IE8の唯一の理論（と "互換モード"ユーザーエージェント）をサポートするようです。

 
cs-uri-stem   MSIEVersion TridentVersion COUNT 
/WebResource.axd  MSIE+8.0 Trident/4.0  100 
/ScriptResource.axd MSIE+8.0 Trident/4.0  36 
/WebResource.axd  MSIE+7.0 Trident/4.0  44 
/ScriptResource.axd MSIE+7.0 Trident/4.0  2 
/ScriptResource.axd NOT IE  NOT Trident  1 

単一の非IE8のエラーは、Firefox/3.5.3ブラウザ（無関係であることを得た）から、まったくクエリ文字列を持っていません。

私のページにMETA HTTP-EQUIV = "Content-Type"はありません。私はJavascriptではないユーザーを跳ね返そうとしていますが。

<noscript> 
    <meta http-equiv=Refresh content="0; URL=/ErrorPage.aspx?Error=NoJavascript"> 
</noscript>