Ich habe eine Silverlight 2 Beta 2-Anwendung, die auf einen WCF-Webdienst zugreift. Aus diesem Grund kann derzeit nur die basicHttp-Bindung verwendet werden. Der Webservice gibt ziemlich große Mengen an XML-Daten zurück. Dies scheint aus Sicht der Bandbreitennutzung ziemlich verschwenderisch zu sein, da die Antwort, wenn sie komprimiert wird, um den Faktor 5 kleiner ist (ich habe die Antwort tatsächlich in eine txt-Datei eingefügt und komprimiert).

Die Anfrage hat die "Accept-Encoding: gzip, deflate" - Gibt es eine Möglichkeit, die Antwort vom WCF-Dienst gzip (oder auf andere Weise zu komprimieren)?

Ich habe das gefundenVerknüpfung aber es scheint sicher ein bisschen komplex für die Funktionalität, die IMHO out-of-the-box gehandhabt werden sollte.

OK - zuerst habe ich die Lösung mit der System.IO.Compression als Antwort markiert, da ich nie den Eindruck hatte, dass die dynamische IIS7-Komprimierung funktioniert. Nun, wie sich herausstellt:

Dynamische Komprimierung unter IIS7war al zusammen arbeiten. Es ist nur so, dass das Web Developer Helper-Plugin von Nikhil für den Internet Explorer nicht funktioniert hat. Ich vermute, da SL den Aufruf des Webdienstes an den Browser weitergibt, wird er vom Browser "unter der Decke" gehandhabt und Nikhils Tool kann die komprimierte Antwort nicht sehen. Ich konnte dies mit Fiddler bestätigen, der den Verkehr außerhalb der Browser-Anwendung überwacht. In Fiddler war die Antwort tatsächlich gzip-komprimiert !!

Das andere Problem mit der System.IO.Compression-Lösung besteht darin, dass System.IO.Compression in der Silverlight-CLR nicht vorhanden ist.

Aus meiner Sicht besteht die EINFACHSTE Möglichkeit, die WCF-Komprimierung in Silverlight zu aktivieren, darin, die dynamische Komprimierung in IIS7 zu aktivieren und überhaupt keinen Code zu schreiben.