http - ブラウザが gzip リクエストを送信できないのはなぜですか?

Question

Web サーバーが gzip 応答を送信できる場合、ブラウザが gzip 要求を送信できないのはなぜですか?

Answer 1

クライアントとサーバーは、通信方法について合意する必要があります。これの一部は、通信を圧縮できるかどうかです。HTTP は要求/応答モデルとして設計されており、当初の作成ではほぼ確実に、常に小さな要求と潜在的に大きな応答が想定されていました。HTTP を実装するために圧縮は必要ありません。圧縮をサポートしていないサーバーとクライアントの両方があります。

HTTP 圧縮は、圧縮をサポートできるというクライアントによって実装されます。サーバーが要求でこれを確認し、圧縮をサポートしている場合、応答を圧縮できます。リクエストを圧縮するには、クライアントは、リクエストが圧縮されることを実際にネゴシエートする「事前リクエスト」を持っている必要があります。または、すべてのリクエストでサポートされているエンコーディングとして圧縮を要求する必要があります。

* UPDATE Feb '17 * 8 年が経ちましたが、@ Phil_1984_ が指摘しているように、3 番目に考えられる解決策は、クライアントとサーバーが圧縮サポートをネゴシエートし、それを後続の要求に使用することです。実際、HSTS のようなものは、サーバーが TLS のみを話し、暗号化されていないリンクを無視することを期待しているクライアント キャッシングでまさにこのように機能します。HTTP は明示的にステートレスになるように設計されていましたが、現時点ではそれを超えています。

Answer 2

クライアントは、サーバーが gzip された要求を理解することを事前に知ることはできませんが、サーバーは、クライアントが要求を受け入れることを知ることができます。

Answer 3

サーバーがそれを受け入れることを保証できれば、可能です。これは、OPTIONS リクエストを使用することを意味する場合があります。

Web ブラウザーで実行できて (パイプライン処理など)、実行できないことはたくさんあります。Web ブラウザの開発者は、変更による互換性への影響を考慮します。

異種環境では、さまざまな Web サーバーと構成が多数存在します。クライアントの作業方法を変更すると、それらの一部が壊れる可能性があります。

おそらく、サーバーの 1% だけが gzip 圧縮されたリクエストを受け入れる可能性がありますが、一部のサーバーは、gzip 圧縮された要求を受け入れることを宣伝していますが、正しく受け入れられない可能性があります。そのため、ユーザーはそれらのサイトにファイルをアップロードすることを拒否されます。

歴史的に、多くの壊れたクライアント/サーバー実装がありました。長い間、主要な Web ブラウザーでは gzip された応答が壊れていました (ありがたいことに、それらは現在ほとんどなくなっています)。

したがって、これらのオプションが自動的にオフになっているユーザーエージェントまたはサーバー (またはドメイン名) のブラックリストが作成されることになり、これは厄介なことです。

Answer 4

サーバーがそれを受け入れることができるかどうかわからないためです。HTTP トランザクションには、クライアントから送信された単一の要求とそれに続く応答があります。クライアントが送信するものの 1 つは、サポートできるエンコード/圧縮です。その後、サーバーは応答を圧縮する方法を決定できます。クライアントにはこの贅沢はありません。

Answer 5

Web アプリケーションを作成している場合、クライアントに送信されるものとクライアントから返されるものを制御していると想定しています。

サーバーに送信される投稿データを圧縮する gzip 実装を JavaScript で記述するのは簡単です。サーバーは、クライアント データが圧縮されて送信されることを認識するフィルター (j2ee 用語) を持つことができます。このフィルターはデータを解凍し、データを通常どおりに読み取るサーブレット (または Struts のアクション クラス) にデータを渡します。 ...)。

これは完全に論理的で実行可能に思えます。他の投稿で言及されているように、これを自動的に実行するためにブラウザーに依存することはできませんでしたが、Web ページを作成しているので、必要な圧縮をブラウザーに実行させることができます (少しの作業で)。

アンディ。