これがSOに属するかどうかは完全にはわかりませんが、他にどこに尋ねればよいかわかりません。
私のWebアプリの読み込み速度を確認しているときに、HTTP応答（html、css、jsの種類に関係なく）がgzip/deflate圧縮されていないことに気付きました。つまり、「Content-Encoding：gzip」のような応答ヘッダーはどのリクエストにも存在せず、ブラウザはリソースが圧縮されていないことを報告します。
- 複数のブラウザ（IE10、FF 17、Chrome 23、Opera 12.10、Safari 5.x）でテストおよび確認されています
- Windows8Proを実行している2台のマシンでテストおよび確認済み
- Fiddlerでダブルチェック-応答は圧縮されておらず、コンテンツエンコーディングヘッダーが含まれていません
- これは私のWebアプリでのみ発生するわけではなく、テストした他のWebサイトは圧縮された応答を送信していないようです（ブラウザーによると）
- Windows 7では、応答は圧縮され、すべてのヘッダーとともに到着します
- HTTPS応答は圧縮されています
応答ヘッダーの例を次に示します（content-encodingヘッダーがないことに注意してください）。
サーバー側もチェックしました。サーバーはWindowsServer2008 R2 /IIS7.5を実行しています。サーバーが何を送信しているかを調べるために、FailedRequestTracingを使用しました。リソースが圧縮されているようです。
また、サーバーは適切なヘッダーを送信しているようです。
私の結論：ここに介入しているのはWindows8であるに違いありません。どうやらそれはHTTP応答を変更します。Windows 8が圧縮された応答を受信し、それを解凍し、コンテンツエンコーディングヘッダーを削除して、変更された応答をパイプラインのさらに下に渡すと仮定します。
今私の質問：
- Windows 8がHTTP応答を変更し、それが私が説明したように機能することを誰かが確認できますか？
- この動作を監視または無効にする方法はありますか？
よろしくお願いします。
よろしく、アンドレ
更新：Wiresharkを使用して、クライアントに何が届くかを確認しました。予想どおり、リソースは圧縮されており、content-encodingヘッダーはまだ存在しています。下の画像はwiresharkプロトコルを示し、右下にはChromeが受信した応答を示しています。
これは、Windows8が介入しているという私の仮定を裏付けています。