2009-07-23 18 views
3

J'ai récemment fait un peu de javascript inter-domaine en utilisant JSONP, et ASP.NET MVC.JQuery, XmlHttpRequest et le code de statut 0

L'action du contrôleur particulière répondra uniquement à une requête POST, ceci est voulu.

Dans IE8, je peux voir (via Fiddler2) que la réponse est correcte, et renvoyer une réponse HTTP 200, avec le javascript JSONP. Dans Firefox, Safari et Chrome, la réponse est toujours renvoyée, avec le code HTTP 200 approprié et le contenu JSONP, la seule différence est que l'objet XmlHttpRequest utilisé par JQuery définit le code d'état sur 0, et le responseText pour vider. À l'origine, je pensais que cela était dû au correctif d'accès HTTP COR (Http Access Control), par lequel un en-tête personnalisé ou un type de contenu autre que text/plain entraînerait l'envoi d'une requête HTTP supplémentaire (avec un OPTIONS). au serveur. Je peux voir dans Fiddler2 que la requête OPTIONS est en cours de réponse avec un HTTP 404.

Le serveur Web est IIS7 (mais le serveur Web de production sera une boîte IIS6). Dans IIS7, je peux voir le standard OPTIONSVerbHandler répertorié dans les gestionnaires, mais je ne suis pas convaincu que cela fonctionne réellement (en fait, je ne trouve même pas de documentation sur OPTIONSVerbHandler n'importe où). Pour contourner cela, j'ai modifié la bibliothèque JQuery pour ne pas définir l'en-tête personnalisé, et changer le type de contenu à text/plain au lieu de application/json, et Firefox commence enfin à contourner la requête OPTIONS, et juste les POST . Le problème réside toujours dans une réponse vide (selon l'objet XmlHttpRequest), même si Fiddler2 montre qu'une réponse HTTP 200 réussie, avec le contenu est retourné.

Une aide?

Répondre

4

Il s'avère que vous ne pouvez pas utiliser les appels inter-domaines avec JQuery en utilisant POST (ce qui est logique, car il rend une étiquette de script pour faire l'appel). Passer à GET a trié le problème, et maintenant tout retourne correctement.

J'ai dû passer en revue la source JQuery pour la trouver, mais merci pour la réponse.

Matt

2

Essayez d'utiliser firebug dans firefox pour voir la demande en cours d'envoi. Consultez l'onglet net pour voir la requête HTTP et la réponse. Peut-être que quelque chose est mal configuré? J'utilise également jsonview dans firefox pour afficher les données JSON qui définissent l'applcaiton/json mimietype. Malheureusement, il ne gère pas JSONP, mais sa fin.

1

Actuellement, ce n'est pas le cas.Firefox envoie un en-tête OPTION comme suit:

Voici ce que se prépare par le client dans Firefox:

 
OPTIONS /MvcApplication/Json/Test1 HTTP/1.1 
Host: acoheni580 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
Accept-Language: en-us,en;q=0.5 
Accept-Encoding: gzip,deflate 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
Keep-Alive: 115 
Connection: keep-alive 
Origin: http://localhost 
Access-Control-Request-Method: POST 

Mvc ne sait pas comment gérer cela parce qu'il est à la recherche que pour un en-tête POST lorsque vous utilisez l'attribut [HttpPost]

Pour autoriser manuellement ceci:

//[HttpPost] 
[AcceptVerbs(new string[] {"POST","OPTIONS"})] 
1

Autre que toutes les erreurs évidentes du côté client, le mai La raison pour cela est que le moteur gecko recherche le Access-Control-Allow-Origin dans l'en-tête du servlet. S'il ne le trouve pas, il annulera la communication et vous obtiendrez un status=0 et un statusText=null. En outre, le moz-nullprincipal en erreur d'analyse XML. Tout cela est très trompeur. Tout ce que vous devez résoudre ce problème est:

response.setHeader("Access-Control-Allow-Origin","*"); 

Dans le code servlet et la vie sera bonne :-)