クライアントとサーバーは、通信方法について同意する必要があります。その一部は、通信を圧縮できるかどうかです。 HTTPは要求/応答モデルとして設計されており、元の作成はほとんど確実に常に小さな要求と潜在的に大きな応答を持つように想定されていました。 HTTPを実装するために圧縮はrequiredではありません。それをサポートしないサーバーとクライアントの両方があります。
HTTP圧縮は、クライアントが圧縮をサポートできると実装しており、サーバーが要求でこれを認識し、圧縮をサポートしている場合、応答を圧縮できます。リクエストを圧縮するには、クライアントは、リクエストが圧縮されることを実際にネゴシエートする「事前リクエスト」を持たなければなりませんORすべてのリクエストに対してサポートされているエンコードとして圧縮を要求する必要があります。
* UPDATE Feb '17 * 8年目ですが、@ Phil_1984_が述べているように、3番目の解決策はクライアントとサーバーが圧縮サポートをネゴシエートし、それを後続のリクエストに使用することです。実際、HSTSのようなものは、サーバーがTLSのみを話し、暗号化されていないリンクを無視することを想定しているクライアントキャッシングでこのように機能します。 HTTPはステートレスになるように明示的に設計されましたが、この時点でそれを超えて移動しました。
クライアントは、サーバーがgzip圧縮された要求を理解することを事前に知ることはできませんが、サーバーはクライアントが要求を受け入れることを知ることができます。
サーバーがそれを受け入れることを保証できれば、それは可能です。これは、OPTIONS要求を使用することを意味する場合があります。
Webブラウザでできること（パイプライン処理など）にはできないことがたくさんあります。 Webブラウザ開発者は、変更が互換性に与える影響を考慮します。
異種環境では、多くの異なるWebサーバーと構成があります。クライアントの動作方法を変更すると、それらの一部が壊れる可能性があります。
サーバーの1％だけがgzip圧縮されたリクエストを受け入れるかもしれませんが、おそらくそれらのいくつかは、それらが正しいことをアドバタイズしますが、正しく受け入れられないため、ユーザーはそれらのサイトにファイルをアップロードできません。
歴史的に、壊れたクライアント/サーバーの実装が多くありました-長い間、主要なWebブラウザでgzip圧縮された応答が壊れていました（ありがたいことに、それらはほとんどなくなっています）。
そのため、これらのオプションが自動的にオフになっているユーザーエージェントまたはサーバー（またはドメイン名）のブラックリストになってしまい、これは厄介です。
サーバーがそれを受け入れられるかどうかわからないからです。 HTTPトランザクションには、クライアントが送信した単一の要求とそれに続く応答があります。クライアントが送信するものの1つは、サポートできるエンコード/圧縮です。サーバーは、応答の圧縮方法を決定できます。クライアントにはこの贅沢はありません。
Webアプリケーションを作成している場合、クライアントに送信されるものとクライアントから返されるものを制御できると想定しています。
サーバーに送信される投稿データを圧縮するgzip実装をjavascriptで記述するのは簡単です。サーバーには、クライアントデータが圧縮されて送信されることがわかっているフィルター（j2ee用語）があり、このフィルターはデータを圧縮解除してから、通常のようにデータを読み取るサーブレット（またはStrutsのアクションクラス）にデータを渡します。 request.getParameter（...）。
これは完全に論理的であり、あなたが管理している場合は実行可能です。他の投稿が言及しているように、これを自動的に行うためにブラウザーに頼ることはできませんでしたが、Webページを作成しているので、ブラウザーに目的の圧縮を実行させることができます（わずかな作業で）。
アンディ。
HTTPは次のように設計されています。
- クライアントはリクエストをプレーンテキストで言います（圧縮された回答を理解できるかどうかを含む）
- サーバーは適切なエンコード（圧縮されているかどうか）で応答します
ただし、この設計では、クライアントは圧縮された要求を送信できません。サーバーが事前にそれを理解するかどうかわからないためです。