Silverlight Network Stack- die Qual der Wahl

Silverlight 3 besitzt 2 Network Stacks. Man merkt davon auf den ersten Blick aber nichts und wozu zwei mal das gleiche?

Bisher hat Silverlight immer den Browser Network Stack verwendet (XMLHTTP). Dies hat eine Menge Vorteile wie z.B. Cookie Support, Caching von Images und wenig Aufwand. Leider auch einen kleinen und einen erheblichen Nachteil: Nur Statusode 404 und 200 und keine DELETE oder PUT Http Kommandos. Nie und nimmer ( auch wenn manche was anderes behaupten). Das ginge ja noch. So wird bei ADO.NET Dataservice ein entsprechender REST Aufruf einfach in einen POST Request getunnelt.

Richtig schlimm wird es aber erst wenn eine Silverlight Anwendung Out off Browser läuft. Wie der Name schon sagt gibt es dann keinen Browser mehr und damit auch keinen Browser Network Stack. Deshalb haben die Jungs vom Silverlight Team den Network Stack in Silverlight nachprogrammiert, nennt sich ClientHttpStack im Gegensatz zum BrowserHttpStack. Allerdings weicht die Implementierung erheblich ab. Caching von Images gibt es z.B. nicht mehr. Man kann für einen einzelnen Webrequest umschalten oder für alles (Images, Webclient, HttpClient, Web Service ect)

Dim httpResult As Boolean = WebRequest.RegisterPrefix("http://", _
    WebRequestCreator.ClientHttp)

Dabei wird für jeweils ein Prefix der ClientHTTP Stack aktiviert. Das kann auch ruhig in der Form http://www ect erfolgen. Das geht allerdings nur einmal pro Anwendungsstart.

Dann gehen auch Request auf REST Services mit GET, POST, DELETE, PUT, OPTIONS und HEAD. Wenn eine Cross Domain Zugriff erfolgen soll muss im Clientaccesspolicy File die http-Methods auf * sein. Ansonsten gibts auch hier nur GET und POST.

Das Thema ist im Detail sehr Umfangreich. Nur um ein paar Stichwörter zu geben, Cookies, Authentifierung, Header, Caching oder Proxy Settings. Dazu später vielleicht mehr.

Kommentare sind geschlossen