2011-07-08 43 views
3

我的Silverlight 4個的應用下載相當多的從通過WCF服務的服務器的數據,所以我使用此處描述的技術實現gzip壓縮:http://forums.infragistics.com/blogs/anton_staykov/archive/2010/08/24/silverlight-wcf-service-compression-azure.aspx鉻未能解壓gzip,內容長度

總之,我擴展WCF gzip編碼器示例(http://msdn.microsoft.com/en-us/library/ms751458.aspx)與Silverlight一起使用。服務器使用gzip壓縮WCF響應,並且在客戶端,瀏覽器HTTP堆棧在到達Silverlight之前自動解壓縮響應。一切都很好,壓縮在IE中非常好用。

測試在Chrome同樣的事情,但是,導致這個..

System.Xml.XmlException: The input source is not correctly formatted. 
at System.Xml.XmlExceptionHelper.ThrowXmlException(XmlDictionaryReader reader, String res, String arg1, String arg2, String arg3) 
at System.Xml.XmlBufferReader.ReadValue(XmlBinaryNodeType nodeType, ValueHandle value) 
at System.Xml.XmlBinaryReader.ReadNode() 
at System.Xml.XmlBinaryReader.Read() 
at System.Xml.XmlBaseReader.ReadEndElement() 
at System.ServiceModel.Channels.Message.ReadFromBodyContentsToEnd(XmlDictionaryReader reader, EnvelopeVersion envelopeVersion) 
at System.ServiceModel.Channels.Message.ReadFromBodyContentsToEnd(XmlDictionaryReader reader) 
at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeBodyContents(Message message, Object[] parameters, Boolean isRequest) 
at System.ServiceModel.Dispatcher.OperationFormatter.DeserializeReply(Message message, Object[] parameters) 
at System.ServiceModel.Dispatcher.ProxyOperationRuntime.AfterReply(ProxyRpc& rpc) 
at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) 
at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result) 
at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result) 
at DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataServiceClient.RealTimeDataServiceClientChannel.EndGetNowTime(IAsyncResult result) 
at DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataServiceClient.DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataService.EndGetNowTime(IAsyncResult result) 
at DataAccess.Model.Silverlight4.DataAccess.RealTimeDataService.RealTimeDataServiceClient.OnEndGetNowTime(IAsyncResult result) 
at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result) 

我已經簽出從提琴手兩種瀏覽器的請求2+應答,而且他們都非常接近相同的,一個重要的差異 - 響應的內容長度設置不正確,因爲Chrome。我確信這就是XML SOAP無法解析的原因。由於內容長度不正確,Chrome只解壓了部分內容。是什麼賦予了?爲什麼我的WCF服務會爲Chrome發送錯誤的內容長度但不是IE?我只改變了瀏覽器 - 代碼是相同的,並且響應體是相同的(Fiddler可以很好地解壓縮)。任何人都知道爲什麼會發生這種情況?

提琴手:

~~ 的Internet Explorer 9 ~~

請求

POST http://127.0.0.1:84/services/RealTimeDataService.svc/binary HTTP/1.1 
Accept: */* 
Referer: http://127.0.0.1:84/ClientBin/Silverlight4.View.xap 
Accept-Language: en-US 
Content-Length: 207 
Content-Type: application/soap+msbin1 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0) 
Host: 127.0.0.1:84 
Connection: Keep-Alive 
Pragma: no-cache 

響應

HTTP/1.1 200 OK 
Cache-Control: private,no-cache 
Pragma: no-cache 
Content-Length: 512 
Content-Type: application/soap+msbin1 
Content-Encoding: gzip 
Server: Microsoft-IIS/7.5 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Fri, 08 Jul 2011 16:18:09 GMT 

~~ ~~

請求

POST http://127.0.0.1:84/services/RealTimeDataService.svc/binary HTTP/1.1 
Host: 127.0.0.1:84 
Connection: keep-alive 
Referer: http://127.0.0.1:84/ClientBin/Silverlight4.View.xap 
Content-Length: 207 
Origin: http://127.0.0.1:84 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30 
content-type: application/soap+msbin1 
Accept: */* 
Accept-Encoding: gzip,deflate,sdch 
Accept-Language: en-US,en;q=0.8 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3 

響應

HTTP/1.1 200 OK 
Cache-Control: private,no-cache 
Pragma: no-cache 
Content-Length: 149 
Content-Type: application/soap+msbin1 
Server: Microsoft-IIS/7.5 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Fri, 08 Jul 2011 16:05:43 GMT 
Content-Encoding: gzip 
+1

很奇怪。我不知道問題是什麼,但是您可以通過創建一個發送IE發送的應用程序來隔離它,然後逐個緩慢更改標題,看起來像Chrome發送的內容,直到找出造成的原因服務器發回不同的響應。 – RobSiklos

+0

是的,這是一個很奇怪的錯誤。感謝您的好主意,我會嘗試隔離哪個請求標頭影響響應。如果我無法弄清楚,我想我必須將解壓縮邏輯放在Silverlight中。 –

+0

有沒有想到這一點? – RobSiklos

回答

0

我最終實現一種變通方法來壓縮WCF服務響應和Silverlight的解壓圖書館。我用SharpZipLib:

  1. 對於Web項目:http://sharpdevelop.net/OpenSource/SharpZipLib/
  2. 的Silverlight版本:http://slsharpziplib.codeplex.com/

在我的WCF服務,我已經從壓縮和非壓縮的方法..壓縮方法返回的byte []在Silverlight端進行解碼。我公開了未壓縮的方法,它返回原始對象,因爲我需要將這些對象的類暴露給客戶端。 (如果任何人有更好的想法如何做到這一點,我很樂意聽到它)

讓你不要設置這些響應的內容編碼HTTP標頭,因爲它們由SL處理客戶端應用程序,而不是瀏覽器。

我從來沒有弄清楚爲什麼Chrome不會自動解壓縮我的WCF響應,但是這種解決方法達到了相同的結果。