HttpWebRequest devuelve 404s para 302 solo en Internet Explorer

Question

Tengo una aplicación Silverlight (v3) que usa WebRequest para realizar una solicitud HTTP POST a una página web en el mismo sitio web que la aplicación Silverlight. Esta solicitud HTTP devuelve un 302 (una redirección) a otra página en el mismo sitio web, que se supone que debe seguir HttpWebRequest (according to the documentation).

No hay nada particularmente especial sobre el código que hace la solicitud (que utiliza la pila HTTP del navegador, que no está configurado para utilizar el suplente incorporado pila HTTP Silverlight):

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

Todo esto funciona bien en Firefox y Chrome; Silverlight hace la petición HTTP POST, recibe una respuesta 302 y automáticamente hace una petición HTTP GET de la URL de redirección especificado y devuelve que a mí (Lo sé porque yo solía Fiddler para ver las peticiones HTTP pasando). Sin embargo, en Internet Explorer (v8), Silverlight hace la petición HTTP POST y luego lanza un WebException con un código de error 404!

Utilizando Fiddler, puedo ver que Silverlight/Internet Explorer devolvió con éxito el código de estado 302 para la solicitud, y supongo que el código de estado 404 (y la WebException asociada) que obtengo en Silverlight se debe a que saber que las solicitudes HTTP que se realizan a través de la pila del navegador solo pueden devolver 200 o 404 debido a limitaciones. La verdadera pregunta es ¿por qué Internet Explorer no sigue a través de la redirección al igual que los otros navegadores?

¡Gracias de antemano por cualquier ayuda!

EDIT: yo preferiría no utilizar la pila de cliente HTTP Silverlight debido a mis solicitudes emitidas por el conocimiento que no incluyen las galletas que son una parte de la sesión del navegador, incluyendo críticamente la cookie de autenticación de ASP.NET que me deben adjuntarse a las solicitudes HTTP que realiza el control de Silverlight.

EDIT 2: He descubierto que Internet Explorer solo muestra este comportamiento cuando realiza una solicitud POST. Una solicitud GET redirecciona con éxito. Esto parece un comportamiento bastante malo teniendo en cuenta cuántos sitios web ahora hacen cosas en el estilo Post-Redirect-Get.

He creado un simple demo VS2008 solution que exhibe este extraño comportamiento, si esto ayuda. Contiene un proyecto básico de ASP.NET MVC 1 y un proyecto de Silverlight 3. Navegue a la página SilverlightControlTestPage.html en el sitio web para ver el problema en acción.

Answer 1

Creo que esto fue un cambio de característica en Internet Explorer 7, donde cambiaron la respuesta esperada de 200 a un IE que decía 302 para ser redirigido. No hay una solución fácil a este problema que yo sepa. Una pregunta similar se planteó hace un tiempo atrás here.

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

Answer 2

IE está más cerca de la especificación, en el que, al responder a un 302 para un puesto de agente de usuario debe enviar un POST (aunque no debería hacerlo sin la confirmación del usuario).

Por otro lado, FF y Chrome son deliberadamente incorrectos al copiar las formas en que los agentes de usuario con frecuencia estaban equivocados hace bastante tiempo (el problema comenzó en los primeros días de HTTP).

Por este motivo, se introdujo 307 en HTTP/1.1 para aclarar que se debe usar el mismo método HTTP (es decir,en este caso, debería ser un POST) mientras que 303 siempre ha significado que uno debe usar GET.

Por lo tanto, en lugar de Response.Redirect que resulta en un 302 - que los diferentes agentes de usuario manejarán de diferentes maneras, envíe un 303. El siguiente código lo hace (e incluye un cuerpo de entidad válido solo para estar dentro de la letra del especulación). Hay una sobrecarga por lo que se puede llamar así, ya sea con un URI o una cadena:

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)); 
}