ajax - ejemplo - xmlhttprequest response

Código de estado HTTP 0: ¿qué significa esto para fetch o XMLHttpRequest?

Question

En cuanto al código de retorno 0 para las llamadas de redes de JavaScript fetch, XMLHttpRequest y MS XMLHTTP, tengo una HTA (aplicación HTML de Microsoft - aplicación HTML + JavaScript fuera de línea) que está utilizando el objeto COM estándar MS XMLHTTP ( Microsoft.XMLHTTP o Msxml2.XMLHTTP dependiendo de versión detectada) a través de código JavaScript para enviar algunos datos al servidor.

Está devolviendo el código de estado 0. Aparentemente, no es un código de estado HTTP válido (deben tener tres dígitos según la especificación oficial). (Por cierto, intenté desconectar la conexión de red y obtuve el código de estado 17003 o algo así, lo que creo que de una gran cantidad de búsquedas en Google significa "error en la búsqueda del servidor DNS").

Funciona bien para mí y para otras personas que lo han probado desde diferentes lugares. Sin embargo, he enviado esto al cliente y han recibido un código de estado HTTP de cero, y el HTTP responseText está en blanco. El cliente lo ha intentado desde dos ubicaciones, pero ambas dentro de su red corporativa.

Esta es una POST de HTTP a una URL de HTTP en Internet (no es una solicitud de archivo: // que entiendo también devolvería el código de estado 0 para tener éxito bajo Mozilla). Estoy bastante seguro de que este es un código de falla, ya que debe devolver alguna confirmación como el texto de responseText , y no estamos obteniendo los datos grabados en la base de datos.

Answer 1

Además de la respuesta de Lee , puede encontrar más información sobre la causa real al cambiar a solicitudes synchronous , ya que también obtendrá una excepción:

function request(url) {
var request = new XMLHttpRequest();
try {
request.open(''GET'', url, false);
request.send(null);
} catch (e) {
console.log(url + '': '' + e);
}
}

Por ejemplo :

NetworkError: Se produjo un error de red.

Answer 2

Como se detalla en esta respuesta en esta página , un código de estado de 0 significa que la solicitud falló por algún motivo, y una biblioteca de JavaScript interpretó el error como un código de estado de 0.

Para probar esto, puede hacer cualquiera de los siguientes:

1) Use esta extensión de Chrome, Requestly para redireccionar su url desde la versión https de su url a la versión http , ya que esto causará un error de seguridad de contenido mixto y, en última instancia, generará un código de estado de 0. La ventaja de este enfoque es que no tiene que cambiar su aplicación en absoluto, y simplemente puede "reescribir" su url usando esta extensión.

2) Cambie el código de su aplicación para hacer que su endpoint redireccione a la versión http de su url en lugar de la versión https (o viceversa). Si haces esto, la solicitud fallará con el código de estado 0.

Answer 3

Creo que el código de error indica que la respuesta estaba vacía (ya que ni siquiera se devolvieron los encabezados). Esto significa que la conexión fue aceptada y luego se cerró con gracia (TCP FIN). Hay una serie de cosas que pueden causar esto, pero en función de su descripción, algún tipo de firewall parece ser el culpable más probable.

Answer 4

En caso de que alguien más se encuentre con este problema, esto me estaba dando problemas debido a la solicitud de AJAX y a una solicitud de formulario normal que se envía. Lo resolví con la siguiente línea:

<form onsubmit="submitfunc(); return false;">

La clave es la devolución falsa, que hace que la forma no se envíe. También puede devolver falso desde el interior de submitfunc (), pero me resulta explícito escribirlo para ser más claro.

Answer 5

En mi caso, el estado se volvió 0 cuando olvidaba poner la WWW en frente de mi dominio. Debido a que todas mis solicitudes ajax estaban codificadas en http: /WWW.mydomain.com y la página web cargada solo sería http://mydomain.com, se convirtió en un problema de seguridad porque es un dominio diferente. Terminé haciendo una redirección en mi archivo .htaccess para poner siempre www en frente.

Answer 6

En mi caso, fue porque el navegador bloqueó la llamada AJAX debido a la misma política de origen . Fue lo menos esperado, porque todos mis HTML y scripts fueron servidos desde 127.0.0.1 . ¿Cómo podrían considerarse como tener orígenes diferentes?

De todos modos, la causa principal era una etiqueta <base> inocente:

<base href=''<%=request.getScheme()%>://<%=request.getServerName() + ":" + request.getServerPort() + request.getContextPath()%>/''/>

Eliminé la etiqueta <base> , que no necesitaba, por cierto, ¡y ahora funciona bien!

Answer 7

Encontré una razón nueva e indocumentada para el estado == 0. Esto es lo que tenía:

XMLHttpRequest.status === 0
XMLHttpRequest.readyState === 0
XMLHttpRequest.responseText === ''''
XMLHttpRequest.state() === ''rejected''

No fue de origen cruzado, red o debido a solicitudes canceladas (por código o por navegación del usuario). Nada en la consola de desarrollador o el registro de red.

Pude encontrar muy poca documentación sobre state () (Mozilla no lo incluye, W3C sí) y ninguno de ellos mencionaba "rechazado".

Resulta que fue mi bloqueador de anuncios (uBlock Origin en Firefox).

Answer 8

Por lo que vale, dependiendo del navegador, las llamadas AJAX basadas en jQuery llamarán a su exitosa devolución de llamada con un código de estado HTTP de 0. Hemos encontrado que un código de estado de "0" generalmente significa que el usuario navegó a una página diferente antes la llamada AJAX completada.

No es la misma tecnología que estás usando, pero afortunadamente es útil para alguien.

Answer 9

Se debe tener en cuenta que una carga de archivo ajax que exceda la directiva client_max_body_size para nginx devolverá este código de error.

Answer 10

Un código de respuesta HTTP de 0 indica que la solicitud AJAX fue cancelada.

Esto puede ocurrir ya sea por un tiempo de espera, un aborto XHR o un firewall que pisa fuerte la solicitud. Un tiempo de espera es común, significa que la solicitud no se ejecutó dentro de un tiempo especificado. Un aborto XHR es muy simple de hacer ... se puede llamar a .abort () en un objeto XMLHttpRequest para cancelar la llamada AJAX. ( Esta es una buena práctica para una aplicación de una sola página si no desea que vuelvan las llamadas AJAX e intente hacer referencia a los objetos que se han destruido. ) Como se menciona en la respuesta marcada, un firewall también podría cancelar la solicitud y activar esto 0 respuesta.

XHR Abort: cancela solicitudes Ajax utilizando jQuery

var xhr = $.ajax({
type: "POST",
url: "some.php",
data: "name=John&location=Boston",
success: function(msg){
alert( "Data Saved: " + msg );
}
});
//kill the request
xhr.abort()

Vale la pena señalar que ejecutar el método .abort () en un objeto XHR también activará la devolución de llamada de error. Si realiza algún tipo de tratamiento de errores que analiza estos objetos, notará rápidamente que un XHR abortado y un XHR de tiempo de espera excedido son idénticos, pero con jQuery, el status de texto que se pasa a la devolución de llamada de error se "abortará" cuando se interrumpa y se produce un "tiempo de espera" con un tiempo de espera excedido. Si está utilizando Zepto (muy similar a jQuery), el errorType será "error" cuando se anule y "timeout" cuando se agote el tiempo de espera.

jQuery: error(jqXHR, textStatus, errorThrown);
Zepto: error(xhr, errorType, error);

Answer 11

wininet.dll devuelve los códigos de estado estándar y no estándar que se enumeran a continuación.

401 - Unauthorized file
403 - Forbidden file
404 - File Not Found
500 - some inclusion or functions may missed
200 - Completed
12002 - Server timeout
12029,12030, 12031 - dropped connections (either web server or DB server)
12152 - Connection closed by server.
13030 - StatusText properties are unavailable, and a query attempt throws an exception

Para el código de estado "cero", ¿está intentando hacer una solicitud en una página web local que se ejecuta en un servidor web o sin un servidor web?

XMLHttpRequest status = 0 y XMLHttpRequest statusText = unknown pueden ayudarte si no estás ejecutando tu script en un servidor web.

Answer 12

Muchas de las respuestas aquí son incorrectas. Parece que las personas averiguan qué estaba causando el estado == 0 en su caso particular y luego lo generalizan como la respuesta.

En términos prácticos, el estado == 0 para un XmlHttpRequest fallido se debe considerar un error indefinido.

La especificación W3C real define las condiciones para las cuales se devuelve cero aquí: https://fetch.spec.whatwg.org/#concept-network-error

Como puede ver en la especificación (fetch o XmlHttpRequest), este código podría ser el resultado de un error que ocurrió incluso antes de contactar al servidor.

Algunas de las situaciones comunes que producen este código de estado se reflejan en las otras respuestas, pero podría ser alguno o ninguno de estos problemas:

1. Solicitud de origen cruzado ilegal (ver CORS )
2. Bloque de firewall o filtrado
3. La solicitud en sí fue cancelada en código
4. Una extensión de navegador instalada está arruinando las cosas

Lo que sería útil sería que los navegadores brinden informes detallados de errores para más de estos escenarios de estado == 0. De hecho, a veces el estado == 0 acompañará un mensaje de consola útil, pero en otros no hay otra información.

Answer 13

Solución alternativa: lo que terminamos haciendo

Pensamos que tenía que ver con los problemas del firewall, por lo que se nos ocurrió una solución que solucionó el problema. Si alguien tiene este mismo problema, esto es lo que hicimos:

1. Todavía escribimos los datos en un archivo de texto en el disco duro local como lo hicimos anteriormente, usando una HTA.

2. Cuando el usuario hace clic en "enviar datos de vuelta al servidor", la HTA lee los datos y escribe una página HTML que incluye esos datos como una isla de datos XML (en realidad, utiliza un bloque de script SCRIPT LANGUAGE = XML).

3. La HTA lanza un enlace a la página HTML en el navegador.

4. La página HTML ahora contiene el javascript que publica los datos en el servidor (usando Microsoft.XMLHTTP).

Espero que esto ayude a cualquier persona con un requisito similar. En este caso, fue un juego Flash utilizado en una computadora portátil en ferias comerciales. Nunca tuvimos acceso a la computadora portátil y solo podíamos enviarla por correo electrónico al cliente ya que esta feria estaba sucediendo en otro país.