JQuery, xmlHttPrequest e código de status 0

Question

Recentemente, tenho feito um JavaScript de domínio cruzado usando o JSONP e o ASP.NET MVC.

A ação do controlador específico responderá apenas a uma solicitação de postagem, isso é por design.

No IE8, posso ver (via Fiddler2) que a resposta está correta e retornando uma resposta HTTP 200, juntamente com o JSONP JavaScript.

No Firefox, Safari e Chrome, a resposta ainda está sendo retornada, com o código HTTP 200 e o conteúdo JSONP apropriado, a única diferença é que o objeto xmlHttPrequest usado pelo jQuery está definindo o código de status como 0 e o responseText para vazio.

Originalmente, eu pensei que isso se deva à pré-flutuação do COR HTTP (controle de acesso HTTP), pelo qual um cabeçalho personalizado ou um tipo de conteúdo que não seja o texto/planície causaria uma solicitação HTTP adicional (com uma opção) o verbo para o servidor. Eu posso ver no Fiddler2 que a solicitação de opções está sendo respondida com um HTTP 404.

O servidor da Web é o IIS7 (mas o servidor da Web de produção será uma caixa IIS6). No IIS7, posso ver o Standard Optionsverbhandler listado nos manipuladores, mas não estou convencido de que isso esteja realmente fazendo nada (na verdade, não consigo nem encontrar nenhuma documentação sobre o optionsverbhandler em qualquer lugar).

Para contornar isso, modifiquei a biblioteca jQuery para não definir o cabeçalho personalizado e alterar o tipo de conteúdo para texto/plano em vez de aplicativo/json, e o Firefox finalmente começa a ignorar a solicitação de opções e simplesmente postagens simples.

O problema ainda está em uma resposta vazia (de acordo com o objeto xmlHttPrequest), embora o Fiddler2 mostre que uma resposta HTTP 200 bem -sucedida, com o conteúdo está sendo retornado.

Qualquer ajuda?

Answer 1

Acontece que você não pode usar chamadas de domínio cruzado com o JQuery usando o Post (o que faz sentido, pois ele renderiza uma tag de script para fazer a chamada). Mudar para resolver o problema e agora tudo está retornando corretamente.

Tive que percorrer a fonte do jQuery para descobrir isso, mas obrigado pela resposta.

Matt

Answer 2

Tente usar Firebug no Firefox para ver a solicitação real sendo enviada. Confira a guia Net para ver a solicitação e resposta HTTP. Talvez algo seja mal configurado? Eu também uso JSONVIEW No Firefox, para visualizar os dados JSON que definem o AppCaiton/JSON Mimietype. Infelizmente, ele não lida com o JSONP, mas está perto.

Answer 3

Além de todos os erros óbvios do lado do cliente, a principal razão para isso é que o mecanismo de Gecko procura o Access-Control-Allow-Origin no cabeçalho do servlet. Se não o encontrar, abortará a comunicação e você recebe um status=0 e statusText=null. Também o moz-nullprincipal no erro de análise XML. Tudo isso é muito enganador. Tudo o que você precisa para resolver esse problema é:

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

No servlet Código e vida serão bons :-)

Answer 4

Na verdade, não é o caso. O Firefox envia um cabeçalho de opção como o seguinte:

Aqui está o que está sendo definido pelo cliente no 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

O MVC não sabe como lidar com isso porque está apenas procurando um cabeçalho de postagem ao usar o atributo [HttpPost]

Para permitir manualmente:

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