リクエストに対してhttp圧縮を有効にすることは可能ですか？
サーバー応答のhttp圧縮を有効にすることに関する多くの情報が表示されますが、着信要求についてはどうでしょう。ブラウザが大きなフォームの投稿をサーバーに送信する前に圧縮するのは意味がないのではないでしょうか。
別の例は、REST使用するWebサービスです。大きなXMLファイル（10+ MB）を使用して頻繁にPUTリクエストを送信する必要があり、帯域幅と速度の両方のメリットが確実に得られます。
これはサーバー側で解決された問題ですか、それとも各Webアプリケーションが個別に処理する必要がありますか？
圧縮されたサーバーにデータをPUTするには、リクエストの本文を圧縮し、Content-Encoding: gzipヘッダーを設定する必要があります。ヘッダー自体は圧縮解除する必要があります。 mod_deflate に記載されています：
Mod_deflateモジュールは、gzip圧縮されたリクエスト本文を解凍するためのフィルターも提供します。この機能をアクティブにするには、SetInputFilterまたはAddInputFilterを使用して、DEFLATEフィルターを入力フィルターチェーンに挿入する必要があります。
...
これで、リクエストにContent-Encoding：gzipヘッダーが含まれる場合、本文は自動的に解凍されます。リクエスト本文をgzip圧縮できるブラウザはほとんどありません。ただし、一部のWebDAVクライアントなど、一部の特別なアプリケーションは実際に要求圧縮をサポートします。
そしてそれを説明する記事は here ：
それで、どうやってそれを行うのですか？これは、再びmod_deflateソースコードからの言い訳です。メインリクエストでのみ機能し、サブリクエストでは機能しません。これは、これを使用することを選択した場合、リクエストの本文全体をgzip圧縮する必要があることを意味します。たとえば、マルチパートリクエストの場合、ファイルを含む部分のみを圧縮することはできません。
これとは別に、ブラウザはAccept-Encodingヘッダーを here のように設定することにより、サーバーの応答コンテンツを圧縮するように要求できます。
GET /index.html HTTP/1.1
Host: www.http-compression.com
Accept-Encoding: gzip
User-Agent: Firefox/1.0
これにより、圧縮されたデータがブラウザーに返されます。
応答ではなく、圧縮された要求に関する部分に答える：はい、それは広く使用されているように見えなくても可能です。クライアント側アプリは、適切なコンテンツエンコーディングヘッダーを設定する必要があります。サーバー側アプリについては、2つの選択肢があります。
アプリは、リクエストボディ自体の再インフレをサポートしています。これを実行できるサンプルライブラリはphpxmlrpcです。
ウェブサーバーは、アプリに渡す前にレスポンスボディを膨らませます。これは、f.e。 Apacheのmod_deflateフィルターとinputFilterのセットアップ
私が知っているどのブラウザからもネイティブではなく、あなたのためにそれを行うプラグインを見つける必要があります。基本的には、コンテンツエンコーディングのHTTPヘッダーを設定して、リクエストの受信方法をサーバーに通知する必要があります。もちろん、サーバーはそのエンコーディングを処理できる必要があります。
これは許可されていません。 HTTP仕様（ RFC 2616 ）によれば、Content-Encodingは可能なリクエストヘッダーフィールドの1つではありません。したがって、これが発生したことをサーバーに通知する正当な方法がないため、リクエストエンティティの本文を圧縮することはできません。リクエストボディの圧縮は、非標準の拡張としてのみ行われます。