ASP.NET MVC: comportement étrange POST

Question

ASP.NET MVC 2 app

J'ai deux actions sur mon contrôleur (Toons):

1. [GET] Liste
2. [POST] Ajouter

L'application fonctionne sur le mode d'intégration IIS7, donc/Toons/List fonctionne correctement. Mais quand je fais un POST (qui redirige vers/Toons/List en interne) il redirige (avec 302 Object Moved) vers/Toons/Add.

Le problème disparaît si j'utilise .aspx hack (qui fonctionne en mode classique IIS6/IIS7).

Mais sans .aspx - GET fonctionne bien, mais le POST me redirige sur lui-même mais avec GET.

Qu'est-ce qui me manque?

J'héberge avec webhost4life.com et ils ont déjà changé IIS7 en mode intégré.

EDIT: Le code fonctionne comme prévu en utilisant le serveur UltiDev Cassini.

EDIT: Il s'est avéré être le problème de trailing-slash-in-URL. D'une manière ou d'une autre, IIS7 n'achemine pas la requête correctement s'il n'y a pas de barre oblique à la fin.

EDET: Explication du comportement
Ce qui arrive est quand je demande (POST) /Toons/List (sans slash), IIS ne trouve pas le gestionnaire (je n'ai pas connaissance de comprendre comment exactement IIS fait URL -manuel de mappage) et redirige la demande (en utilisant le code 302) vers /Toons/List/ (remarque slash).

Un navigateur, selon la spécification HTTP, doit rediriger la requête en utilisant même méthode (POST dans ce cas), mais il gère 302 comme si elle est de 303 et les questions GET demande de la nouvelle URL.

Ceci est incorrect, mais le comportement connu de la plupart des navigateurs. La solution consiste à utiliser .aspx-hack pour rendre IIS sans ambiguïté la correspondance entre les requêtes et le gestionnaire ASP.NET, ou à configurer IIS pour gérer tout ce qui se trouve dans le répertoire virtuel à l'aide du gestionnaire ASP.NET.

Q: Quelle est une meilleure façon de gérer cela?

Answer 1

Vous avez le contrôle sur votre code. modifier toutes les pages qui font un post sans la barre oblique finale pour publier sur la bonne page. si ses clients tiers, que de retourner une exception, qu'ils devraient corriger le bogue.

Ceci est un comportement attendu, et ce n'est pas à vous de récupérer tout ce qui peut arriver. mais vous devez donner de bons indices (par exemple, un message d'exception, au lieu d'une erreur ou une redirection bizarre).