ASP.NET MVC: Comportamiento posterior a la extraña

Question

ASP.NET MVC 2 aplicación

Tengo dos acciones en mi controlador (Toons):

1. [GET] Lista
2. [mensaje] Agregar

La aplicación se ejecuta en modo de integración IIS7, por lo que/Toons/List funciona bien. Pero cuando hago POST (que redirige a/Toons/List internamente) redirige (con 302 Object Moved) a/Toons/Add.

El problema desaparece si uso .aspx hack (que funciona en modo clásico IIS6/IIS7).

Pero sin .aspx - GET funciona bien, pero POST me redirige a sí mismo pero con GET.

¿Qué me estoy perdiendo?

Estoy alojado en webhost4life.com y ya cambiaron IIS7 al modo integrado.

EDIT: El código funciona como se esperaba utilizando el servidor UltiDev Cassini.

EDIT: Resultó ser un problema de trailing-slash-in-URL. De alguna manera, IIS7 no enruta la solicitud correctamente si no hay una barra al final.

Edet: Explicación del comportamiento
Lo que pasa es que solicito (POST) /Toons/List (sin barra final), IIS no encontrar el controlador (no tengo el conocimiento para entender cómo funciona exactamente IIS URL -to-handler mapping) y redirige la solicitud (usando el código 302) a /Toons/List/ (observe la barra diagonal).

Un navegador, de acuerdo con la especificación HTTP, debe redirigir la solicitud usando el mismo método POST (en este caso), pero en su lugar se maneja 302 como si fuera 303 y cuestiones LLEGAR solicitud de la nueva URL.

Esto es incorrecto, pero el comportamiento conocido de la mayoría de los navegadores.

La solución consiste en utilizar .aspx-hack para dejar inequívoco para IIS la forma de asignar solicitudes al controlador ASP.NET, o configurar IIS para manejar todo en el directorio virtual mediante el controlador ASP.NET.

Q: ¿Cuál es la mejor manera de manejar esto?

Answer 1

Tiene control sobre su código. cambie todas las páginas que hacen una publicación sin la barra al final para publicar en la página correcta. si sus clientes de terceros, que devuelven una excepción, deben corregir el error.

comportamiento esperado, y no es su trabajo recuperar todo lo que pueda suceder. pero debe dar buenos consejos (por ejemplo, mensaje de excepción, en lugar de un extraño error o redirección)