5

数日前にこの質問をしましたが、あまり反応がありませんでした。そして、これはおそらく私の質問が無意味だったからだと思いました。

http についての私の理解では、クライアント (通常はブラウザー) が要求 (取得) をサーバー (私の場合は IIS) に送信します。このリクエストの一部は、accept-encoding ヘッダーです。これは、クライアントがリソースを返すことを希望するエンコーディングのタイプをサーバーに示します。通常、これには gZip が含まれます。サーバーが正しく設定されていれば、要求されたエンコーディングで要求されたリソースが返されます。

応答には、リソースに適用された圧縮を示す Content-Encoding ヘッダーが含まれます。応答には、リソースの MIME タイプを示す Content-Type ヘッダーも含まれます。そのため、応答に Content-Type : application/json と Content-Encoding: gzip の両方が含まれている場合、クライアントはリソースが gzip を使用して圧縮された json であることを認識します。

現在、私が直面しているシナリオは、ブラウザーではなくモバイル デバイスであるクライアント向けの Web サービスを開発しており、これらのデバイスはリソースを要求する代わりに、処理するサービスにデータを投稿するというものです。

だから私は、本文にjsonを含むポストリクエストを受け入れるRestfullサービスを実装しました。私のクライアントは Content-Type:Application/json で投稿リクエストを送信します。しかし、私のクライアントの中には、送信を高速化するためにリクエストを圧縮したいというリクエストがありました。しかし、私の理解では、リクエストの本文が gZip を使用してエンコードされていることをリクエストで示す方法はありません。

つまり、リクエストには content-Encoding ヘッダーはなく、レスポンスのみです。

これは事実ですか?

リクエストを圧縮しようとする http の使用法が間違っていますか?

4

1 に答える 1

3

SO に関する別の回答によると、リクエストに Content-Encoding ヘッダーを付けてエンティティをデフレートして送信するのは、HTTP 標準の範囲内です。

ただし、データを自動的に膨らませるサーバーはないようです。そのため、サーバー側のコードを自分で記述する必要があります (要求ヘッダーを確認し、それに応じて対応してください)。

于 2012-09-11T03:15:12.870 に答える