HttpWebRequest renvoie 404s pour 302s seulement dans Internet Explorer

Question

J'ai une application Silverlight (v3) qui utilise WebRequest pour faire une demande HTTP POST à ​​une page Web sur le même site Web que l'application Silverlight. Cette requête HTTP renvoie un 302 (une redirection) vers une autre page sur le même site Web, que HttpWebRequest doit automatiquement suivre (according to the documentation).

Il n'y a rien particulièrement spécial sur le code qui fait la demande (il utilise la pile HTTP de navigateur, il n'est pas configuré pour utiliser la pile HTTP Silverlight alternatif intégré):

HttpWebRequest request = (HttpWebRequest)WebRequest.Create(String.Format("{0}?name={1}&size={2}", _UploadUrl, Uri.EscapeUriString(Name), TotalBytes)); 
request.Method = "POST"; 

Tout cela fonctionne très bien dans Firefox et Chrome; Silverlight fait la requête HTTP POST, reçoit une réponse 302 et fait automatiquement une requête HTTP GET de l'URL de redirection spécifiée et me la renvoie (je le sais parce que j'ai utilisé Fiddler pour regarder les requêtes HTTP en cours). Toutefois, dans Internet Explorer (v8), Silverlight exécute la requête HTTP POST, puis lance une exception WebException avec un code d'erreur 404! En utilisant Fiddler, je peux voir que Silverlight/Internet Explorer a été retourné avec succès le code d'état 302 pour la demande, et je suppose que le code d'état 404 (et WebException associé) que je reçois dans Silverlight est parce que connaître les requêtes HTTP qui sont effectuées via la pile du navigateur ne peut renvoyer que 200 ou 404 en raison de limitations. La vraie question est pourquoi Internet Explorer ne suit pas la redirection comme les autres navigateurs?

Merci d'avance pour toute aide!

EDIT: Je préférerais ne pas utiliser la pile HTTP client Silverlight, car à mes demandes de connaissances qu'elle a émises, ne comprennent pas les cookies qui font partie de la session du navigateur, y compris de façon critique le cookie d'authentification ASP.NET que je doivent être attachés aux requêtes HTTP effectuées par le contrôle Silverlight.

EDIT 2: J'ai découvert qu'Internet Explorer ne présente ce problème que lorsque vous effectuez une requête POST. Une requête GET redirige avec succès. Cela semble plutôt mauvais comportement compte tenu du nombre de sites Web font maintenant des choses dans le style Post-Redirect-Get.

J'ai créé un simple demo VS2008 solution qui présente ce comportement étrange, si cela aide. Il contient un projet de base ASP.NET MVC 1 et un projet Silverlight 3. Accédez à la page SilverlightControlTestPage.html sur le site Web pour voir le problème en action.

Answer 1

Je crois qu'il s'agissait d'un changement de fonctionnalité dans Internet Explorer 7, où par ils ont changé la réponse attendue de 200 à un 302 indiquant IE à être redirigé. Il n'y a pas de solution facile à ce problème que je connais. Une question similaire a été posée il y a un certain temps here.

Change in behavior with Internet Explorer 7 and later in regard to CONNECT requests

Answer 2

IE est plus proche de la spécification, en ce que répondre à un 302 pour un POST l'agent utilisateur doit envoyer un POST (mais il ne devrait pas le faire sans confirmation de l'utilisateur). D'un autre côté, FF et Chrome ont délibérément tort, en copiant des fautes fréquentes d'agents utilisateurs depuis longtemps (le problème a commencé dans les premiers jours de HTTP). Pour cette raison, 307 a été introduit dans HTTP/1.1 pour être plus clair sur le fait que la même méthode HTTP devrait être utilisée (c'est-à-dire, par exemple, que l'on a utilisé 307).dans ce cas, il devrait être un POST) alors que 303 a toujours signifié que l'on devrait utiliser GET. Par conséquent, au lieu de faire Response.Redirect, ce qui aboutit à un 302 - que différents agents utilisateurs géreront de différentes manières, envoyez un 303. Le code suivant le fait (et inclut un corps d'entité valide juste pour être dans la lettre du spec). Il y a une surcharge de sorte que vous pouvez l'appeler avec soit un Uri ou une chaîne:

private void SeeOther(Uri uri) 
{ 
    if(!uri.IsAbsoluteUri) 
    uri = new Uri(Request.Url, uri); 
    Response.StatusCode = 303; 
    Response.AddHeader("Location", uri.AbsoluteUri); 
    Response.ContentType = "text/uri-list"; 
    Response.Write(uri.AbsoluteUri); 
    Context.ApplicationInstance.CompleteRequest(); 
} 
private void SeeOther(string relUri) 
{ 
    SeeOther(new Uri(Request.Url, relUri)); 
}