經過壓縮的HTTP應答報文是由瀏覽器解壓的，用wireshark抓包可以看到客戶端主機接收到的HTTP應答報文仍然是壓縮的，而且wireshark可以將該HTTP應答解壓（是否讓wireshark解壓是可以設置的，茲不贅述）。比起壓縮，解壓的速度是非常快的（只要數據正常，可以解壓的話），所以不用擔心瀏覽器用於解壓的時間會降低用戶體驗。事實上，瀏覽器解壓消耗的這點時間比起數據包因爲網絡擁堵而耽誤的時間要少的多也可控的多。
在瀏覽器發給服務器的HTTP請求報文中，使用Accept-Encoding字段標明自己支持的壓縮格式，即自己可以解壓哪幾種壓縮報文（gzip、zlib庫提供的deflate）。服務器回覆客戶端的HTTP應答報文中，使用Content-Encoding字段標明該應答報文使用哪種壓縮方式。如下圖所示，
必須要說明的是，這裏有些地方，實際的實現方式和RFC文檔中提到的方式並不相同。《HTTP權威指南》第370頁明確說明Accept-Encoding字段支持Q值，而且說“如果HTTP請求沒有包含Accept-Encoding首部，服務器就可以假設客戶端能夠接受任何編碼方式”。可現實是，對於一般大型網站，比如百度、新浪、騰訊等，只有客戶端HTTP請求帶着Accept-Encoding字段，對應的HTTP應答纔會將HTTP應答數據壓縮（而且有的網站根本不關心客戶端支持哪種壓縮格式，只判斷有沒有這個首部，如果有，就統一用gzip壓），如果不帶這個字段，服務器發來的HTTP應答數據就是未經過壓縮的（顯然服務器並沒有默認客戶端能夠接收任何編碼方式）！！！而且服務器“根本不識別Q值”！！！發送一個帶着Q值的HTTP請求報文，得到的結果卻並沒有按照Q值的規則來！！！更可氣的是，我原以爲只有國內的網站這麼做，後來測試了下國外網站，發現都是這樣。對於一些特別細節的地方，比如對某些異常的處理（e.g.請求報文中Accept-Encoding字段只有該首部而沒有對應的內容，就像這個樣子“Accept-Encoding： ”而不是“Accept-Encoding： gzip, deflate”），不同的網站具體的處理方式也是不同的，這裏不再贅述，想要分析，直接抓包即可。關於Q值的問題，因爲現網處理非常簡單粗暴，因此這裏也不再贅述，只要大家知道現網是這麼幹的就夠，這裏就不貼圖了，想實踐直接抓包就行。