IIS 8.0でURLをフォローしてgzip圧縮を有効にしました Gzipを有効にするIIS )==外部レストサービスを呼び出していますアプリケーションからjquery ajax呼び出しとC#コードを介して、現在、私の外部Webサービスはgzip圧縮されていません。サービスパートナーに応答のgzipを要求する場合、jquery側とc#側でコードに解凍ロジックを記述する必要がありますか、それともブラウザが自動的に応答を解凍しますか?
すべての最新のブラウザーは、gzipエンコードされた応答を処理できます。実際、リクエストを見ると、Accept-Encoding: gzip
の行に沿って何かを示すヘッダーがあり、gzip圧縮された応答を処理できることをサーバーに伝える方法です。
重要な部分は、サーバーがそのヘッダーの存在と値に応じて、gzip応答と非圧縮応答の両方を返すことができるということです。クライアントがAccept-Encoding
ヘッダーを送信しない場合は、圧縮しないでください。クライアントが送信する場合は、オプションでgzipを使用して応答をエンコードできます。既に圧縮されている可能性があり、CPUサイクルを浪費しているため、すべてのコンテンツを圧縮する必要はありません。通常、JPEG画像がこの良い例です。おそらく、IISはここでもインテリジェントな決定を行っており、必要な場合にのみ必要なものだけを圧縮しています。
IISがサーバーから返された応答ヘッダーとContent-Encoding: gzip
ヘッダーを確認することで、本来あるべきことを実行していることを確認できます。これにより、クライアントまたはブラウザに、コンテンツはgzip圧縮を使用してエンコードされており、適切に解凍する必要があります。
すべてのブラウザーベースのリクエスト(XHR/AJAX/jQuery、通常のリクエストなど)は、ユーザーの追加作業なしで自動的に解凍されます。ブラウザは、gzipを処理できるかどうかを判断するクライアントであり、可能であればAccept-Encoding
ヘッダーを追加します。 JavaScriptコードは、レスポンスハンドラーで圧縮されていないバージョンを受け取ります。
TL; DR:通常は有効にすることをお勧めします。追加の作業を行う必要はありません。
Gzip圧縮が有効になっている場合Webサーバー上、つまりアプリケーションロジックではない場合、ブラウザーは自動的に解凍されます。
実際、ブラウザーが圧縮をサポートしていない場合、Webサーバーは圧縮されていないデータを送信します(この情報は、ブラウザーとWebサーバーの間で交換される要求/応答のHTTPヘッダーにあります)。圧縮は、JPEGおよびその他のすでに圧縮された形式では効果がないことに注意してください。