Можно ли перехватывать ошибки 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, определенных в спецификациях API CORS.

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

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

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

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