1. Inicio
  2. Pregunta y respuesta
  3. ¿Cuándo debe disparar el controlador onerror de XMLHttpRequest?

¿Cuándo debe disparar el controlador onerror de XMLHttpRequest?

2012-05-14 7 views
36

Tengo un pequeño problema para comprender los controladores de XMLHttpRequest. The specification says this about the onerror handler:¿Cuándo debe disparar el controlador onerror de XMLHttpRequest?

error [Se distribuye ...] Cuando la solicitud ha fallado.

load [Despachado ...] Cuando la solicitud se ha completado correctamente.

El problema es, ¿qué significa que "la solicitud ha fallado". Eso podría ser

  • la solicitud no pudo ser emitido en absoluto (por ejemplo. Conexión rechazada y este tipo de errores), o
  • lo anterior más el servidor devuelve un código de error (por ejemplo. 404)

Además, me gustaría saber si significa que onerror y onload nunca deberían disparar simultáneamente.

This reference indica el manejador onerror debe ser ejecutado en función del código status y onload dependiendo de readyState. Eso indicaría que no son mutuamente excluyentes, sin embargo, no creo que esta sea una información autorizada.

Pregunto porque utilizando la última instantánea de Opera, encontré onload disparado incluso en el código de estado 404. Sé que probar status es una apuesta segura, pero me gustaría saber si es algo que tengo que hacer por especificación o solo una solución para un error en Opera.

Fuente

2012-05-14 jpalecek

+4

Tomo 'ha completado con éxito' para indicar que recibe un código de estado, ya sea 200 OK o un código de error como 404. Chrome también se activa aunque el código de estado sea un código de estado de error. – Snuffleupagus

+1

onerror y onload nunca disparar simultáneamente. Es uno o el otro. Sin embargo, onloadend dispara en ambos casos y es el último evento de la fila. – jayarjo

Respuesta

57

Como se menciona en los comentarios, onerror se dispara cuando hay un error en el nivel de red . Si el error solo existe en el nivel de la aplicación, p. Ej., Se envía un código de error HTTP, entonces onload todavía se activa. Debe probar el código de estado devuelto explícitamente en su controlador onreadystatechange.

Tenga en cuenta que una solicitud de dominio rechazado también activará el controlador onerror.

Fuente

2012-05-14 13:41:11 apsillers

+0

Hmm, extraño. ¿Puedes (o alguien) explicar el comportamiento de Google Server? – jpalecek

+0

Hice una prueba más completa y descubrí que encrypted.google.com no envía 404 para esa solicitud: el miembro 'status' de la solicitud XHR es en realidad' 0', donde otros servidores envían un 404.Aparentemente ese servidor de repente pretende que no existe en absoluto cuando ve una solicitud de una página que no existe. Extraño, pero esa es la decisión de Google. – apsillers

+6

O ... podría ser porque al tocar 'https: // encrypted.google.com/foobar' redirige a' http: // www.google.com/foobar', y el navegador se niega a participar en un cruce redirigir el dominio durante una solicitud de Ajax. – apsillers

1

Además de la respuesta de los apsillers, tenga en cuenta que XMLHttpRequest maneja los redireccionamientos automáticamente en segundo plano, por lo que no tiene que verificar estos códigos de respuesta en el evento onload (este evento se invocará solo una vez, en la última llamada) También tenga en cuenta que, en caso de que envíe datos de carga útil con el método POST, y si las solicitudes se redireccionan, XMLHttpRequest cambiará el método de POST a GET y descartará cualquier dato de carga útil por razones de seguridad. El evento onload aún se invocará, pero deberá volver a enviar su solicitud manualmente al nuevo destino.

Fuente

2016-08-14 07:55:23 StanE

Cuestiones relacionadas

 Cuestiones relacionadas