2012-02-02 171 views
6

這是我們的場景中(這是沒有商量餘地):透明GZIP壓縮

  • WCF REST服務公開了使用IIS7託管WebHttpEndpoint HTTP
  • 所有響應和POST請求數據以JSON形式傳輸
  • 非WCF Web客戶端
  • 我們已經在IIS7中爲JSON響應激活了gzip壓縮,並且工作正常。

由於我們正在做更大的JSON負載的發佈請求,我們已經爲JSON發佈數據實現了客戶端GZIP壓縮,並將「Content-Encoding」頭設置爲「gzip」。不幸的是IIS不能處理這個問題。發佈數據以壓縮形式到達WCF解串器,這當然會導致異常。

我試過各種擴展點掛鉤到WCF管道,但唯一有希望的解決方案(操作行爲)沒有工作,因爲沒有WCF客戶端,IOperationBehavior接口的ApplyClientBehavior方法將永遠不會被調用。

在如果實施的HttpModule它能夠完成任務,但我不是,因爲以下注意事項的結果正是幸福的結尾:

  • 雖然我能夠通過設置透明地解壓縮請求數據當前HttpRequest的Filter屬性爲GZipInputStream,這只是解決方案的一半,因爲WCF堅持從請求中準確讀取HttpRequest.ContentLength字節,對於壓縮請求將明顯比未壓縮的有效負載小得多
  • 出於某種奇怪的原因我的想象力微軟已經阻止了每一種合法的方式來改變r的ContentLength eQUEST的。最後,我不得不修改請求的ContentLength屬性的專用支持字段。這不是你想要在生產代碼中做的事情。
  • 微軟也使人們無法讀取HTTP模塊請求的InputStream弄清楚這需要我們的網絡客戶端還傳遞包含未壓縮的內容長度

這所有的一切感覺就像一個自定義標題中的未壓縮的內容長度很多工作甚至無法完全實現,所以我想知道是否有人可以指出在IIS中實現解壓縮部分的替代方案。如果有商業產品的話,我完全可以推薦它。

+0

你找到了一個解決方案? – Snowy 2012-05-22 03:46:45

+0

有沒有人找到解決方案? – 2013-01-10 16:35:39

+0

似乎沒有一個已知的解決方案。 – 2013-01-15 15:02:30

回答

0

我想你應該能夠與service side Message inspector

解壓爲此在AfterReceiveRequest

+0

不幸的是,調度消息檢查器在管道中執行得太晚。我已經嘗試過了,傳遞給檢查員的消息已經處於錯誤狀態。 – 2012-02-02 09:59:37

+0

您是否在服務端使用端點上的GZip編碼器進行了研究http://msdn.microsoft.com/zh-cn/library/cc138373(v=VS.90).aspx或者至少有一個解碼GZip但通常編碼 – 2012-02-02 10:52:33