¿Es posible atrapar errores de CORS?

Question

Esta pregunta está relacionada con la compartición de recursos de origen cruzado (CORS, http://www.w3.org/TR/cors/).

Si se produce un error al realizar una solicitud de CORS, Chrome (y otros navegadores de AFAIK también) registran un error en la consola de error. Un mensaje de ejemplo puede verse así:

XMLHttpRequest no se puede cargar http://domain2.example. El origen http://domain1.example no está permitido por Access-Control-Allow-Origin.

Me pregunto si hay una forma de obtener este mensaje de error mediante programación. Intenté ajustar mi llamada xhr.send() en try/catch, también intenté agregar un controlador de eventos onerror(). Ninguno de los cuales recibe el mensaje de error.

Answer 1

Ver:

• http://www.w3.org/TR/cors/#handling-a-response-to-a-cross-origin-request

... así como las notas en XHR nivel 2 sobre CORS:

• http://www.w3.org/TR/XMLHttpRequest2/

La información es intencionalmente filtrado.

Editar muchos meses después: Un comentario de seguimiento aquí preguntó por "por qué"; al presentador del primer enlace le faltaban algunos caracteres que dificultaban ver a qué parte del documento me refería.

Es una cuestión de seguridad: un intento de evitar la exposición de información en encabezados HTTP que podrían ser sensibles. El enlace del W3C sobre CORS dice:

Los agentes de usuario deben filtrar todas las cabeceras de respuesta distintos de los que son una cabecera de respuesta simple o de los cuales el nombre del campo es un caso-insensibles partido ASCII para uno de los valores de la Los encabezados de Access-Control-Expose-Headers (si corresponde), antes de exponer los encabezados de respuesta a las API definidas en las especificaciones de CORS API.

Ese pasaje incluye enlaces para "encabezado de respuesta simple", que enumera Cache-Control, Content-Language, Content-Type, Expira, Last-Modified y Pragma. Entonces esos pasan. La parte de "Access-Control-Expose-Headers headers" permite que el servidor remoto exponga otros encabezados también al listarlos allí. Consulte la documentación del W3C para más información.

Recuerde que tiene un origen, digamos que es la página web que ha cargado en su navegador, ejecutando algo de JavaScript, y el script está realizando una solicitud a otro origen, lo que normalmente no está permitido porque el malware puede hacer cosas desagradables de esa manera. Por lo tanto, el navegador, ejecutando el script y realizando las solicitudes HTTP en su nombre, actúa como guardián.

El navegador mira la respuesta de ese servidor de "otro origen" y, si no parece estar "participando" en CORS - los encabezados requeridos faltan o están mal formados - entonces estamos en una posición de sin confianza No podemos estar seguros de que el script que se está ejecutando localmente esté actuando de buena fe, ya que parece estar intentando contactar servidores que no esperan ser contactados de esta manera.El navegador ciertamente no debe "filtrar" ninguna información sensible de ese servidor remoto simplemente pasando toda su respuesta al script sin filtrar, que básicamente sería permitiendo una solicitud de origen cruzado, de tipo. Una vulnerabilidad de divulgación de información surgiría.

Esto puede dificultar la depuración, pero se trata de una cuestión de seguridad frente a usabilidad donde, dado que el "usuario" es un desarrollador en este contexto, la seguridad tiene una prioridad importante.