使用http壓縮時的內容長度

Question

客戶端向http服務器發出範圍請求0-1023。它喜歡用gzip壓縮 Accept-Encoding：gzip; q = 1.0，identity;在請求中q = 0.5，*; q = 0 。

響應頭中的內容長度是多少？它會是1024或壓縮數據的大小。

謝謝，

Answer 1

它是1024或壓縮大小中的較小者。

RFC2616 section 14說：

「 [這個答案的其餘部分沒有相關性要求的實際問題，我把它留在因爲有些人發現它是有用的。]

2616有這說（除其他事項外）大約的Content-Length：

應用程序應使用該字段來指示的 轉印長度的消息體，除非這是由規則部禁止4.4。

所以我們必須弄清楚傳輸長度是多少; Section 4.4（信息長度）說，大約轉發長度這兩件事情：

消息的轉發長度是所述消息體的長度爲 它出現在消息中;也就是說，在任何傳輸編碼已經應用 之後。

如果存在內容長度標頭字段（14.13節），則其OCTET中的其十進制值 表示實體長度和傳輸長度。如果 這兩種長度不同

奧凱的Content-Length頭字段絕不能發送，因此我們知道，在這種情況下，傳輸長度，實體長度和內容長度都具有相同的價值，並且都參考「郵件中出現的郵件正文的長度」，因此我們必須確定郵件正文是什麼。 Section 4.3說，這大約消息體：

的消息體（如果有的話）的HTTP消息被用於攜帶與該請求或響應相關聯的 實體主體「

所以。什麼是一個實體機構，你必須是指基本上所有的Section 7（也定義了實體的長度。）最重要的是，有這樣的：？

實體主體：=內容編碼（內容 - 類型（數據））

實體主體的長度（以及因此我們的內容長度每4.4的值）是內容編碼之後的數據長度。

Answer 2

實際內容長度取決於傳輸編碼和數據：如果使用標識，則不應用壓縮，並且內容長度爲1024;如果使用gzip，則實際內容長度取決於要壓縮的數據。

Answer 3

實際上它會是1024這是壓縮數據的大小。