問題タブ [content-encoding]

やるかどうかというと、現在の状況はどうですか？

または

たとえば、帯域幅が制限されているクライアントが、圧縮された応答を受け入れる意思があることを通知し、サーバーが圧縮するかどうかを最終的に決定できるようにしたい場合。

後者は、たとえば Apache の mod_deflate と IIS が圧縮を処理する場合に行うことです。圧縮するコンテンツのサイズに応じて、追加のTransfer-Encoding: chunked.

Vary: Accept-Encodingまた、すでに問題を示唆しているも含まれます。Content-Encodingエンティティの一部であるように見えるため、Content-Encoding金額をエンティティの変更に変更すると、つまり、Accept-Encodingヘッダーが異なると、たとえば、キャッシュは、それ以外の場合は同一のエンティティのキ​​ャッシュされたバージョンを使用できなくなります。

私が見逃した明確な答えはありますか(そして、それはいくつかのApacheニュースグループの長いスレッドのメッセージ内に埋もれていません)?

私の現在の印象は次のとおりです。

• 実際、Transfer-Encoding は、既存のサーバーとクライアントの実装によって Content-Encoding でほとんど行われていることを行う正しい方法です。
• ETagContent-Encoding は、そのセマンティックな意味合いのために、いくつかの問題を抱えています (サーバーが応答を透過的に圧縮する場合、サーバーは何をすべきでしょうか?)
• その理由はニワトリと卵です: サーバーがサポートしていないため、ブラウザーがサポートしていないため、ブラウザーがサポートしていません。

したがって、正しい方法は a になると想定していますTransfer-Encoding: gzip(または、さらに体をチャンクすると、 になり Transfer-Encoding: gzip, chunkedます)。Varyそして、それはトランスポートレベルのものであるため、その場合、またはETag他のヘッダーに触れる理由はありません。

今のところ、私は の「ホップバイホップ」性についてはあまり気にしていません。これはTransfer-Encoding、プロキシが圧縮解除され、圧縮解除された状態でクライアントに転送される可能性があるためです。ただし、元のリクエストに適切なAccept-Encodingヘッダーが含まれている場合、プロキシはそれをそのまま（圧縮して）転送することもできます。これは、私が知っているすべてのブラウザーの場合です。

ところで、この問題は少なくとも 10 年前のものです。たとえば https://bugzilla.mozilla.org/show_bug.cgi?id=68517を参照してください。

これに関する説明をいただければ幸いです。標準に準拠していると見なされるものと、実用的であると見なされるものの両方の観点から。たとえば、透過的な「Content-Encoding」のみをサポートする HTTP クライアント ライブラリは、実用性に反する議論になります。

HTTP ContentEncoding "deflate"の処理に関連して、とストリームのOutputStream両方をインフレートするためにを使用する方法を知りたいです。理由は次のとおりです。gzipdeflate

Webサーバーからリソースをフェッチするクラスがあります（wgetJavaで考えてみてください）。私はそれを厳密に施行しています-応答の内容の長さ-その施行を維持したいと思います。したがって、私がやりたいのは、応答から特定のバイト数を読み取ることです（これはすでに実行しています）が、応答が圧縮されている場合は、より多くのバイトを生成します。

私はこれを次のdeflateような応答のために機能させています：

レスポンスでも同じことができるようにしたいと思いますがgzip、GunzipOutputStreamがないと、次に何をすべきかわかりません。

アップデート

私はこのようなものを作ることを考えていましたが、それは完全に正気ではないようでした。おそらく、それがOutputStream私のデータを膨らませるためにを使用する唯一の方法です。

gzip について質問があります。サーバーが「Content-Encoding: gzip」ヘッダーを追加するとします。ただし、実際のコンテンツは gzip されません (圧縮に失敗し、圧縮せずにデータを送信していると仮定します)。これはどのような影響を与えるでしょうか？http クライアント (特にブラウザ) はこれをどのように処理しますか?

ありがとう、ナレンドラ

自分のサイトでGZIPエンコーディングを使用したいのですが、どのようにすればよいですか。HTMLファイルのコンテンツエンコーディングをに設定しましたgzip。

Tはこのように試しました

ApacheTomcatWebサーバーを使用しています。

HTTP 応答のメッセージ本文が Base64 でエンコードされているかどうかを知る方法はありますか?

content-transfer-encoding が HTTP ヘッダーの一部ではないことを知りました。

では、コンテンツが Base64 でエンコードされていることを示す HTTP ヘッダーはどれでしょうか? Content-encoding は圧縮にのみ使用されると思います。

png 画像用の RESTful Web サービスを実装するために Jersey (ver 1.9.1) を使用しています。クライアント側で Apache HttpClient (ver. 4x) を使用しています。クライアント側のコードは、HttpGet を呼び出して画像をダウンロードします。ダウンロードが成功すると、InputStream が HttpEntity からディスクに保存されます。問題は結果ファイルであり、サーバー上のファイルは異なります。クライアント コードによって生成された出力イメージ ファイルはレンダリングできません。

以下の私のクライアントコードは、上記のリソースメソッドを呼び出します

ここでの問題は、サーバーに存在するファイルとダウンロードされたファイルが異なることです。

以下は、サーバーに存在するファイルのダンプです。

以下は、ダウンロードしたファイルのダンプです。

ご覧のとおり、いくつかのバイトが変更されています。JerseyサーバーAPIは、ファイルからストリーム内のデータを変更していますか? 何がうまくいかないのですか？

アップデート：

ブラウザから同じ URL にアクセスすると、ファイルはダウンロードされますが、ダウンロードしたファイルは表示されません。したがって、問題はサーバーに関連しているようです。

/Tomcat 6.0/conf 内の server.xml ファイルを以下に示します。

たくさんのサイトを参考にしました。皆、同じことを言っています。私もそうでした。しかし、なぜ私は望ましい出力を作ることができません。gzip が機能していません。応答ヘッダーにコンテンツ エンコーディングがありません。見逃したものはありますか？

いくつかのファイルを S3 バケットにアップロードしています。1 つの zip ファイルと 1 つの .json ファイル。

それらをアップロードすると、両方のファイルが次のようになります。

zip ファイルには次のものが必要です。

これらのファイルが目的のタイプ/エンコーディングでアップロードされていることを確認するにはどうすればよいですか?

以下は私のコードの一部です：

ファイルの保存:

ファイルのアップロード:

私が達成しようとしていること：

私は自動提案機能に取り組んでいます。プレーンなjsonファイルをアップロードすると1.5MBを超えてしまい、大変です。したがって、次善の策は、ZIP ファイルをアップロードすることです (ファイルを 300kb に減らします)。ユーザーがページをロードすると、ブラウザは解凍する必要があります。何らかの理由で、コンテンツ タイプ/エンコーディングを指定された作品に設定するだけで、他のすべてが失敗します。

ユーザーが大きなテキスト ファイル (1 ～ 15 MB) の CSV ファイルをダウンロードする必要が
あり、Excel を使用して編集した後 、同じページの Web ブラウザーを使用してサイトに
そのまま再アップロード (編集された CSV)する状況があります。

ダウンロード
に gzip エンコーディングが適用され、ユーザーに送信されるコンテンツは gzip 圧縮されます (firebug で確認)

問題は 、ユーザーが編集したファイルを再アップロードすると、
圧縮されていないテキストとして送信されることです (そうですか?)。
制限されたユーザー帯域幅 (約 50 ～ 128 KBps アップロード)
と非常に大規模なユーザー ベース (100 人以上の同時ユーザー)では 、同時アップロード/ダウンロードが実行される
と、サイトが許容できないパフォーマンス (1 分以上の応答時間)に追い込まれます。

質問:
バック グラウンドで gzip コンテンツ エンコーディングと圧縮を使用し て、HTTP Post 経由でクライアント ブラウザにファイル アップロードを送信させるにはどうすればよい
ですか?

アップロードする前にファイルを圧縮するようにユーザーに指示することはできます
が、さまざまなアーカイブ ファイル形式が生成される可能性が
あり、ユーザーが「アーカイブ」を採用するための手順を追加するという状況を考慮すると、実行可能なオプションではありません。

編集

サーバー側の解凍処理​​は、すでにビジー状態のサーバーに負担を追加します。

言い換えた

一方、さまざまな形式のサーバー側の解凍ロジックは
、サーバー側のコードを複雑にします。 圧縮を使用することで転送時間と帯域幅の使用量が削減さ
れるため、圧縮解除の負荷自体は許容範囲内です。

情報

• サーバー: IIS
  
• ASP.NET MVC 3、
  Visual Studio 2010 C# 4.0、
  DevExpress 12 MVC 拡張機能、
  UploadControl コンポーネントを使用して作成
  

同様の質問では、望ましい答えが得られません。

ブラウザから送信された HTTP 投稿データの圧縮

一部は未回答のままです:

投稿データの http 圧縮を実装する