爲什麼POST方法中的GZIP壓縮請求正文不常見？

Question

我用GZIP壓縮最近在玩周圍，我理解的方式如下：

1. 客戶端從Web服務器請求一些文件或數據。客戶端還發送一個報頭，說：「接受編碼，壓縮程序」
2. Web服務器檢索文件或數據，壓縮它們，並將它們發送回gzip壓縮到客戶端。 Web服務器還會發送一個標題「Content-Encoded，gzip」來向客戶說明數據是否被壓縮。
3. 客戶端然後去壓縮用戶數據/文件並加載它們。

我知道這是很常見的做法，當需要加載需要大量HTML，CSS和JavaScript的頁面時，這會很有意義，並且可以添加到您的瀏覽器的加載時間。

不過，我是想深入瞭解一下這個，爲什麼它不常見的GZIP壓縮請求主體做一個POST調用時？是否因爲通常請求主體很小，所以在Web服務器上解壓縮文件需要的時間比簡單地發送請求花費的時間要長？有什麼文件或參考我可以有關於此？

謝謝！

Answer 1

這是罕見的，因爲在客戶端 - 服務器的關係，在服務器中的所有數據發送到客戶端，正如你提到的，來自客戶端的數據往往是小的，因此壓縮很少帶來任何性能提升。

在REST API，我要說的是，這並非罕見可言，但顯然Spring框架，爲他們的REST工具已知的，不同意 - 他們明確地說in their docs here，您可以設置servlet容器做響應壓縮，而沒有提到請求壓縮。由於Spring Framework的操作模式是提供他們認爲很多人會使用的功能，他們顯然不覺得值得提供一個我們用戶可以用來讀取壓縮請求體的實現。

這將是有趣的拖網的tomcat，支柱，傑克遜，GSON等的用戶郵件列表進行類似的討論。

如果你想編寫自己的解壓過濾器，嘗試閱讀本：How to decode Gzip compressed request body in Spring MVC

或者，把你的servlet容器背後提供了更多功能的Web服務器。顯然，人們需要足夠的請求壓縮以便像Apache這樣的Web服務器提供它 - 這個回答已經很好地總結了這一點：HTTP request compression - 您也會在那裏找到對HTTP規範的引用。