HTTP 302 Перенаправление на запрос CORS отбрасывается браузерами

Я загружаю HTML-страницу с некоторым javascript с сайта A.

Javascript отправляет HTTP-запрос GET на сайт B. На этом этапе:
- браузер отправляет запрос OPTIONS на сайт B
- сайт B отвечает на запрос OPTIONS
- браузер затем отправляет исходный запрос HTTP GET на сайт B
- сайт B отвечает HTTP 302 с местоположением, установленным на сайт C.

В этот момент браузер перестает обрабатывать запрос. Я ожидал, что он отправит запрос HTTP OPTIONS на сайт C так же, как и при отправке запроса на сайт B. Но это не так. Я наблюдал такое же поведение в Firefox и Chrome.

Я хотел бы понять, почему браузеры ведут себя таким образом. Я понимаю, что для предотвращения циклов, но не ограничено 2 запроса перенаправления, должны быть некоторые проверки или максимальные переадресации.

Также почему информация заголовка НЕ отправляется в код Javascript, чтобы приложение могло что-то с этим сделать. Он просто отбрасывается браузером, хотя он дразнит вас, показывая HTTP 302 Response с сайта C с URL-адресом местоположения в консоли браузера.

XMLHttpRequest не может загрузить https://siteB/... Запрос был перенаправлен на 'https://siteC/.. ', который запрещен для запросов с кросс-началом, требующих предполетной проверки.

Любые идеи дизайна искренне приветствуются.

Привет

Ответ 1

Ну, у меня была та же проблема, что и вы, и, к сожалению, это поведение нормально, в соответствии со спецификацией W3C

Эта спецификация описывает поведение браузера относительно CORS как состояния машины, и если вы переходите к шагу 3 (выполняя фактический запрос), в нем четко говорится:

Это фактический запрос. Примените шаги make request и соблюдайте правила запроса ниже при оформлении запроса.

Если ответ имеет код состояния HTTP 301, 302, 303, 307 или 308 Примените шаги кэширования и сетевой ошибки.

Итак, если я правильно понимаю, мы не можем ожидать, что браузер автоматически выполнит перенаправление в случае CORS (предположительно, поскольку OPTION предоставил доступ к другому ресурсу? Но тогда почему бы не автоматически отправить другой запрос OPTION на этот ресурс?).

Что еще хуже, поскольку HEADERS ответа скрыты браузером после того, как автоматическое перенаправление завершилось неудачно по причине выше, у нас нет доступа к заголовку Location, чтобы обрабатывать последующий вызов на правильный ресурс самостоятельно. Таким образом, в этом случае невозможно извлечь фактический ресурс.

Я считаю, что это ошибка, но я не мог найти хороший пост по этому вопросу в Интернете.

Обходной путь, если это возможно для вас, заключается в том, чтобы не выполнять запрос CORS, а вместо этого использовать простой запрос (в соответствии со спецификацией снова, например, просто GET без пользовательских заголовков), что не вызовет никаких предпродажных запросов отправляться: в этом случае перенаправление работает нормально (автоматически за которым следует браузер).

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

Если у кого-то есть достоверная информация о том, почему это поведение, пожалуйста, укажите свой вклад: -)

Надеюсь, что это поможет.