Ich habe eine Silverlight (v3) -Anwendung, die WebRequest verwendet , um eine HTTP-POST-Anfrage an eine Webseite auf derselben Website wie die Silverlight-App zu senden. Diese HTTP-Anfrage erhält eine 302 (eine Weiterleitung) zu einer anderen Seite auf derselben Website zurück, die HttpWebRequest soll automatisch folgen ( gemäß der Dokumentation ).
Es gibt nichts besonderes an dem Code, der die Anfrage ausführt (er verwendet den HTTP-Stack des Browsers, er ist nicht für die Verwendung des alternativen Silverlight-HTTP-Stacks konfiguriert):
%Vor%All das funktioniert in Firefox und Chrome gut; Silverlight macht die POST-HTTP-Anfrage, empfängt eine 302-Antwort und führt automatisch eine GET-HTTP-Anfrage der angegebenen Weiterleitungs-URL aus und gibt diese an mich zurück (Ich weiß dies, weil ich Fiddler verwendet habe, um die HTTP-Anfragen zu verfolgen). In Internet Explorer (v8) führt Silverlight jedoch die POST-HTTP-Anforderung aus und löst dann eine WebException mit einem 404-Fehlercode aus!
Mit Fiddler kann ich sehen, dass Silverlight / Internet Explorer den 302-Statuscode für die Anfrage erfolgreich zurückgegeben hat, und ich nehme an, dass der 404-Statuscode (und die zugehörige WebException), die ich in Silverlight erhalte, so weit ich weiß HTTP-Anfragen, die über den Browser-Stack ausgeführt werden, können aufgrund von Einschränkungen nur 200 oder 404 zurückgeben. Die eigentliche Frage ist Warum folgt der Internet Explorer nicht der Umleitung wie die anderen Browser ?
Vielen Dank im Voraus für jede Hilfe!
BEARBEITEN: Ich würde es vorziehen, den Silverlight-Client-HTTP-Stack nicht zu verwenden, da von ihm ausgegebene Anfragen keine Cookies enthalten, die Teil der Browser-Sitzung sind, einschließlich ASP.NET Authentifizierungscookie, die ich an die HTTP-Anforderungen anhängen muss, die vom Silverlight-Steuerelement ausgeführt werden.
BEARBEITEN 2: Ich habe festgestellt, dass Internet Explorer dieses Verhalten nur bei einer POST-Anfrage zeigt. Eine GET-Anfrage wird erfolgreich umgeleitet. Dies scheint ein ziemlich schlechtes Verhalten zu sein, wenn man bedenkt, wie viele Websites nun im Post-Redirect-Get-Stil arbeiten.
Ich habe eine einfache Demo-VS2008-Lösung erstellt, die dieses seltsame Verhalten zeigt, wenn es hilft. Es enthält ein grundlegendes ASP.NET MVC 1-Projekt und ein Silverlight 3-Projekt. Navigieren Sie zur Seite SilverlightControlTestPage.html auf der Website, um das Problem in Aktion zu sehen.
IE ist näher an der Spezifikation, da der Benutzeragent beim Antworten auf einen 302 für einen POST einen POST senden sollte (obwohl dies nicht ohne Benutzerbestätigung erfolgen sollte).
Auf der anderen Seite sind FF und Chrome absichtlich falsch darin, Wege zu kopieren, auf denen Benutzeragenten vor langer Zeit oft falsch waren (das Problem begann in den frühen Tagen von HTTP).
Aus diesem Grund wurde 307 in HTTP / 1.1 eingeführt, um deutlicher zu machen, dass dieselbe HTTP-Methode verwendet werden sollte (dh in diesem Fall sollte es ein POST sein), während 303 immer bedeutete, dass man GET verwenden sollte.
Anstatt also Response.Redirect zu verwenden, was zu einem 302 führt, mit dem verschiedene Benutzeragenten auf unterschiedliche Weise umgehen, senden Sie eine 303. Der folgende Code tut dies (und enthält einen gültigen Entity-Body, der nur innerhalb des Buchstabens von die Spezifikation). Es gibt eine Überladung, so dass Sie sie entweder mit einem Uri oder einem String aufrufen können:
Ich glaube, das war eine Feature-Änderung in Internet Explorer 7, bei der die erwartete 200 Antwort auf eine 302 geändert wurde, die den IE anweist, umgeleitet zu werden. Es gibt keine glatte Lösung für dieses Problem, das ich kenne. Eine ähnliche Frage wurde eine Weile zurück gestellt hier .
Verhaltensänderung mit Internet Explorer 7 und höher in Bezug auf CONNECT-Anfragen
Tags und Links internet-explorer .net c# silverlight httpwebrequest