JQuery, XmlHttpRequest e Codice di Stato 0

Question

Recentemente ho fatto un po ' di domini javascript utilizzando JSONP, e ASP.NET MVC.

Il particolare Controller azione solo rispondere a una richiesta POST, questo è il design.

In IE8, posso vedere (via Fiddler2) che la risposta è corretta, e la restituzione di una risposta HTTP 200, insieme con il JSONP javascript.

In Firefox, Safari e Chrome, la risposta è ancora restituito, con gli opportuni HTTP 200 codice e JSONP contenuto, l'unica differenza è che l'oggetto XmlHttpRequest essere utilizzato da JQuery è l'impostazione del codice di stato a 0, e il responseText a vuoto.

Inizialmente, ho pensato che questo era a causa di COR HTTP Preflight (Http Access Control), per cui un'intestazione personalizzata o un tipo di contenuto diverso text/plain causerebbe un ulteriore richiesta HTTP (con OPZIONI) verbo essere inviati al server.Posso vedere in Fiddler2 che le OPZIONI di richiesta a cui si è risposto con un HTTP 404.

Il server web è IIS7 (ma il server web di produzione, sarà un IIS6 box).In IIS7, riesco a vedere lo standard OPTIONSVerbHandler elencati nei gestori, ma io non sono convinto che questo è in realtà fare niente (in effetti, anche io non riesco a trovare la documentazione su OPTIONSVerbHandler ovunque).

Per ovviare a questo, ho modificata la libreria JQuery per non impostare l'intestazione personalizzata, e modificare il contenuto di tipo text/plain invece di application/json, e Firefox inizia finalmente ignorando le OPZIONI di richiesta, e solo un semplice Post.

Il problema si trova ancora in una risposta vuota (secondo l'oggetto XmlHttpRequest), anche se Fiddler2 mostra che il successo di una risposta HTTP 200, con il contenuto viene restituito.

Qualsiasi aiuto?

Answer 1

Scopre, non è possibile utilizzare chiamate Cross-Domain con JQuery POST (il che ha senso, come si esegue il rendering di un tag script per effettuare la chiamata).Di commutazione per OTTENERE risolto il problema, e ora tutto è tornato correttamente.

Era a piedi attraverso JQuery fonte per capire che uno, ma grazie per la risposta.

Matt

Answer 2

Prova a usare piromane in Firefox per vedere la richiesta effettiva viene inviato. Controlla la scheda rete per vedere la richiesta HTTP e la risposta. Forse qualcosa è configurato correttamente? Io uso anche JSONView in Firefox per visualizzare i dati JSON che imposta l'mimietype applcaiton / JSON. Purtroppo non gestisce JSONP, ma la sua stretta.

Answer 3

Oltre a tutti gli evidenti errori sul lato client, la ragione principale di questo è che il motore Gecko cerca il Access-Control-Allow-Origin nel colpo di testa da servlet. Se non lo trova, si interrompe la comunicazione e si ottiene un status=0 e statusText=null. Inoltre, il moz-nullprincipal in XML errore di analisi. Tutto questo materiale è molto fuorviante. Tutto ciò che serve per risolvere questo problema è:

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

Nel codice servlet e la vita sarà un bene :-)

Answer 4

In realtà non è così. Firefox manda un colpo di testa OPZIONE come il seguente:

Ecco cosa sta ottenendo impostato dal client in 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 non sa come gestire questo perché è solo alla ricerca di un colpo di testa POST quando si utilizza il [HttpPost] attributo

Per consentire manualmente questa:

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