職場の Windows 7 64 ビット PC で奇妙な問題が発生しています。私は gzip 圧縮されたコンテンツ (js、css、html) を提供する Linux Web サーバーをいくつか管理しています。奇妙な動作は、システム内のすべてのブラウザー (Firefox、Chrome、Vivaldi) がそれらの Linux サーバーにコンテンツを要求しても (ヘッダーはAccept-Encoding: gzip,deflate問題なく表示されます)、コンテンツが取得されないことです。すべての応答に が付属しているTransfer-Encoding: chunkedため、コンテンツは圧縮された状態で提供されません。ただし、オプションcurlを使用してコマンド ラインで実行すると--compressed、応答にContent-Type: gzipおよびContent-Lengthヘッダーが付属し、想定どおり gzip 圧縮されます。Windows 2008 R2 サーバーからは、コンテンツは gzip 圧縮された状態で提供されます。
コンテンツを gzip 形式で提供することは、これらの Linux Web サーバーでは問題なく動作することが保証されています。
pfSense プロキシが関係していますが、プロキシ設定でこれを上書きして、ブラウザーが Linux サーバーから直接コンテンツを要求するようにしても、動作は同じです。プロキシの有無にかかわらず、変化はありません。
別の Windows 7 64 ビット PC で Firefox と Chrome の問題を確認しました。そのため、この奇妙なブラウザの動作には OS が何らかの形で関与しているという結論に達しました。
誰か確認してくれませんか…？
答え1
これは誤解を招く可能性があります。gzip されたファイルを 1 つのメッセージで送信するには、サーバーがファイル全体を使用可能にしてそのサイズを把握している必要がありますが、あなた自身が言ったように、あなたのケースではそれが起こらないようです。
オプションを指定してコマンドラインで curl を実行すると
--compressed、応答にヘッダーが付属しContent-Type: gzip、Content-Length想定どおりに gzip 圧縮されます。
あなたの場合、サーバーはパイプ出力を gzip に圧縮し、ファイル サイズを計算するために最初にデータをディスクに書き込むことなく、結果をブラウザに直接パイプします。サイズが事前にわからないため、サーバーは、Transfer-Encoding: chunked利用可能な部分のストリームを返すしかありません。
データが利用可能になると、チャンクで返され、ブラウザによって再構成されます。ただし、チャンクで受信された場合でも、受信データは gzip 圧縮されたままです。