在 Apache 中啟用 gzip 壓縮時未發送內容長度？

我非常感謝您對理解這種 Apache 行為的幫助。

我正在從 application/json 中的 iPhone Objective-C 應用程序與 PHP 通信。Gzip 壓縮在伺服器上啟用，並由客戶端請求。

從我的 .htaccess 中：

AddOutputFilterByType DEFLATE text/html text/plain text/xml application/x-httpd-php application/json

對於小請求，Apache 正在設置“Content-Length”標頭。例如（這些值在 Objective-C 中從標頭輸出）：

Connection = "Keep-Alive";
"Content-Encoding" = gzip;
"Content-Length" = 185;     <-------------
"Content-Type" = "application/json";
Date = "Wed, 22 Sep 2010 12:20:27 GMT";
"Keep-Alive" = "timeout=3, max=149";
Server = Apache;
Vary = "Accept-Encoding";
"X-Powered-By" = "PHP/5.2.13";
"X-Uncompressed-Content-Length" = 217;

X-Uncompressed-Content-Length是我添加的一個標頭，設置為未壓縮 JSON 字元串的大小。

如您所見，這個請求非常小（217 字節）。

這是來自更大請求（282888 字節）的標頭：

Connection = "Keep-Alive";
"Content-Encoding" = gzip;
"Content-Type" = "application/json";
Date = "Wed, 22 Sep 2010 12:20:29 GMT";
"Keep-Alive" = "timeout=3, max=148";
Server = Apache;
"Transfer-Encoding" = Identity;
Vary = "Accept-Encoding";
"X-Powered-By" = "PHP/5.2.13";
"X-Uncompressed-Content-Length" = 282888;

請注意，沒有給出 Content-Length。

我的問題：

1. 為什麼 Apache 不為更大的請求發送 Content-Length？
2. ‘Contend-Encoding=gzip’ 設置的事實是否意味著 gzip 壓縮仍在處理更大的請求，即使我無法驗證大小差異？
3. 有沒有辦法讓 Apache 包含這些較大請求的實際 Content-Length 以更準確地向使用者報告數據使用情況？

這個應用程序可以用於昂貴的數據計劃，因此我希望向使用者報告實際使用情況，而不是 30-70% 的誇大使用情況（幾百額外的 KB 可能聽起來不多——但這些計劃的成本可能在 $ 1 and $ 每 MB 10 個！）。

提前致謝。

除了 Martin Fjordvalds 的回答：

僅當壓縮文件大小大於 DeflateBufferSize 時，Apache 才使用分塊編碼。因此，增加此緩衝區大小將阻止伺服器對較大的文件也使用分塊編碼，從而導致即使對於壓縮數據也發送 Content-Length。

更多資訊可在此處獲得：http ://httpd.apache.org/docs/2.2/mod/mod_deflate.html#deflatebuffersize

聽起來 Apache 正在執行分塊編碼，這意味著它可以在壓縮數據時發送數據，而不是等待完整的響應被壓縮。這是相當標準的做法，不過我對 Apache 還不夠熟悉，不能說它是否可以被禁用。

引用自：https://serverfault.com/questions/183843