2011-07-08 10 views
3

マイシルバー4アプリのダウンロード、GZIPを解凍するWCFサービスを介して、サーバからのデータのかなりのコンテンツ長を失敗したので、私はここに記載された技術を用いて、gzip圧縮を実装:要するにhttp://forums.infragistics.com/blogs/anton_staykov/archive/2010/08/24/silverlight-wcf-service-compression-azure.aspxクロム

、Iは、拡張Silverlightで動作するWCF gzipエンコーダサンプル(http://msdn.microsoft.com/en-us/library/ms751458.aspx)。サーバーは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) 

私はバイオリン弾きで両方のブラウザからの要求+応答をチェックアウトしてきた、と彼らは非常にほぼ同一であり、重要な1で差異 - レスポンスのContent-LengthがChromeで正しく設定されていません。私はこれがXML SOAPが解析するのに失敗した理由だと確信しています。Chromeは、コンテンツの長さが間違っているためにコンテンツの一部を解凍するだけです。何がありますか?なぜ私のWCFサービスは、IEではなく、Chromeの間違ったコンテンツ長を返送するのですか?私は何も変えないが、ブラウザのコードは同一であり、レスポンスのボディは同じである(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

非常に奇妙です。私は何が問題なのか分かりませんが、Internet Explorerが送信するものを正確に送信するアプリケーションを作成し、ヘッダーを1つずつゆっくりと変更して、何が原因であるかを知るまでChromeが送信しているように見えるようにすることで、異なる応答を返すためのサーバー – RobSiklos

+0

ええ、それはかなり奇妙なエラーです。良いアイデアをお寄せいただきありがとうございます。私はどのリクエストヘッダーがレスポンスに影響を与えるのかを特定しようとしますもし私がそれを理解できなければ、私はSilverlightの中に圧縮解除ロジックを置かなければならないと思う。 –

+0

これを理解する運がありますか? – RobSiklos

答えて

0

私は、WCFサービスの応答を圧縮し、Silverlightの上でそれを解凍するための回避策を実装することになりましたとしょうかん。 ]、私のWCFサービスでhttp://slsharpziplib.codeplex.com/

Iは、圧縮と非圧縮の両方の方法を持っている...圧縮方法は[バイトを返す:http://sharpdevelop.net/OpenSource/SharpZipLib/

  • Silverlightのバージョン:Webプロジェクトのために

    1. :私はSharpZipLibを使用しましたこれはSilverlight側でデコードされます。私は、クライアント側に公開されるこれらのオブジェクトのクラスが必要なので、未加工のメソッドを公開します。 (誰もがこれを行う方法の良いアイデアを持っている場合、私はそれを聞いてみたい)

      は、それらがSLによって処理されるようおは、これらの応答のためのコンテンツをコードするHTTPヘッダーを設定していないくださいブラウザではなく、クライアントアプリケーションです。

      ChromeがWCFレスポンスを自動的に解凍しない理由を決して特定できませんでしたが、この回避策でも同じ結果が得られます。