Можно ли перехватывать ошибки CORS?

Question

Этот вопрос связан с совместным использованием ресурсов из разных источников (CORS, http://www.w3.org/TR/cors/).

Если при выполнении запроса CORS возникает ошибка, Chrome (а также AFAIK и другие браузеры) регистрирует ошибку на консоли ошибок. Пример сообщения может выглядеть так:

XMLHttpRequest не может загрузить http://domain2.example, происхождения http://domain1.example не допускается Access-Control-Allow-Origin.

Мне интересно, есть ли способ программно получить это сообщение об ошибке? Я пытался обернуть xhr.send() позвоните в try / catch, я также попытался добавить onerror() обработчик события. Ни один из которых не получает сообщение об ошибке.

Answer 1

Увидеть:

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

... а также заметки в XHR Level 2 о CORS:

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

Информация намеренно фильтруется.

Отредактируйте много месяцев спустя: следующий комментарий здесь спросил "почему"; якорь в первой ссылке пропускал несколько символов, из-за чего было трудно понять, на какую часть документа я ссылаюсь.

Это вопрос безопасности - попытка избежать раскрытия информации в заголовках HTTP, которая может быть конфиденциальной. Ссылка W3C о CORS говорит:

Пользовательские агенты должны отфильтровывать все заголовки ответа, кроме тех, которые являются простым заголовком ответа или именем поля которого является ASCII-регистрозависимое совпадение для одного из значений заголовков Access-Control-Expose-Headers (если есть), перед предоставлением заголовков ответов API, определенным в спецификациях CORS API.

Этот отрывок содержит ссылки для "простого заголовка ответа", в котором перечислены Cache-Control, Content-Language, Content-Type, Expires, Last-Modified и Pragma. Так что те проходят. Часть "Заголовки Access-Control-Expose-Headers" позволяет удаленному серверу выставлять и другие заголовки, перечисляя их там. См. Документацию W3C для получения дополнительной информации.

Помните, что у вас есть один источник - скажем, это веб-страница, которую вы загрузили в своем браузере, на которой выполняется немного JavaScript - и скрипт выполняет запрос к другому источнику, что обычно не разрешается, потому что вредоносные программы могут делать неприятные вещи, которые путь. Таким образом, браузер, запускающий скрипт и выполняющий HTTP-запросы от его имени, выступает в роли привратника.

Браузер просматривает ответ от этого "другого источника" и, если кажется, что он "не участвует" в CORS - требуемые заголовки отсутствуют или искажены - тогда мы не можем доверять. Мы не можем быть уверены, что скрипт, работающий локально, работает добросовестно, поскольку, похоже, он пытается связаться с серверами, которые не ожидают, что с ним будут связываться таким образом. Браузер, конечно, не должен "пропускать" какую-либо конфиденциальную информацию с этого удаленного сервера, просто передавая весь свой ответ сценарию без фильтрации - это, по сути, будет разрешать запросы разных типов. Уязвимость раскрытия информации может возникнуть.

Это может усложнить отладку, но это компромисс между безопасностью и удобством использования, когда, поскольку "пользователь" является разработчиком в этом контексте, безопасности придается значительный приоритет.