使用.net 4 WCF壓縮

這使服務器忽略另外的強制性規定Content-Length頭，作爲一般的HTTP頭，具有在HTTP主體之前。（設置chunked編碼affects the way the body gets encoded。）所以，現在它可以即時壓縮響應主體，即在壓縮時吐出字節，而不必等待整個身體的壓縮完成，只是爲了能夠確定壓縮結果的內容長度。這可以節省服務器端的大量內存。（客戶端，然而，現已置於暗處作爲對壓縮的響應的總大小，直到它完成接收整個響應，使得它的減壓略微低效率）

注意然而，使用Accept-Encoding和Content-Encoding，正如我剛纔所描述的，以透明壓縮反應竟是a stupid idea，根據HTTP合着者羅伊菲爾丁，哪些應該被使用，而不是在請求以下標題：

TE: gzip, deflate

而SERV呃，如果選擇進行壓縮，將下面的頭添加到它的響應：

Transfer-Encoding: gzip, chunked

和以前一樣，chunked如果服務器要省略Content-Length是必要的。

否則，TE/Transfer-Encoding組合是語法上等同於所述Accept-Encoding/Content-Encoding組合，但含義是不同的，如可以從this longish discussion中收集。

問題的要點是：TE /傳輸編碼使得壓縮運輸細節，而接受編碼/內容編碼表示壓縮版本作爲實際數據（在HTTP用語實體），具有後者緩存請求，代理等不幸後果的數量。然而，TE/Transfer-Encoding船很早就航行了，而且我們被AE/CE組合所困住，它受到大多數客戶和服務器的支持，其含義實際上更接近於TE/TE

當談到壓縮請求在HTTP，他們很少在實踐中使用，且有客戶端要弄清楚，如果服務器支持，沒有標準的方式。您可以通過帶外（例如硬編碼）告訴客戶服務器瞭解壓縮請求（和configure the server appropriately）。或者你有你的客戶主動嘗試壓縮一次，如果它產生一個400 Bad Request（至少這是一個IIS 7.5將返回），你回落到非壓縮請求。

來源

2014-04-08 07:44:53

請注意，壓縮已添加到WCF 4.5。都能在這裏找到：http://msdn.microsoft.com/en-us/library/aa751889(v=vs.110).aspx

你必須使用一個自定義綁定來啓用它：

<customBinding> 
    <binding name="BinaryCompressionBinding"> 
    <binaryMessageEncoding compressionFormat="GZip"/> 
    <httpTransport /> 
    </binding> 
</customBinding>

只用二進制編碼工作。此外，你必須意識到你的情況。如果您在IIS中託管，則壓縮可能已經開啓。請看這裏：http://blogs.msdn.com/b/dmetzgar/archive/2011/04/29/automatic-decompression-in-wcf.aspx

來源

2014-04-16 23:39:23

使用.net 4 WCF壓縮

回答

相關問題