Ответ 1
Ну, у меня была та же проблема, что и вы, и, к сожалению, это поведение нормально, в соответствии со спецификацией W3C
Эта спецификация описывает поведение браузера относительно CORS как состояния машины, и если вы переходите к шагу 3 (выполняя фактический запрос), в нем четко говорится:
Это фактический запрос. Примените шаги make request и соблюдайте правила запроса ниже при оформлении запроса.
Если ответ имеет код состояния HTTP 301, 302, 303, 307 или 308 Примените шаги кэширования и сетевой ошибки.
Итак, если я правильно понимаю, мы не можем ожидать, что браузер автоматически выполнит перенаправление в случае CORS (предположительно, поскольку OPTION предоставил доступ к другому ресурсу? Но тогда почему бы не автоматически отправить другой запрос OPTION на этот ресурс?).
Что еще хуже, поскольку HEADERS ответа скрыты браузером после того, как автоматическое перенаправление завершилось неудачно по причине выше, у нас нет доступа к заголовку Location, чтобы обрабатывать последующий вызов на правильный ресурс самостоятельно. Таким образом, в этом случае невозможно извлечь фактический ресурс.
Я считаю, что это ошибка, но я не мог найти хороший пост по этому вопросу в Интернете.
Обходной путь, если это возможно для вас, заключается в том, чтобы не выполнять запрос CORS, а вместо этого использовать простой запрос (в соответствии со спецификацией снова, например, просто GET без пользовательских заголовков), что не вызовет никаких предпродажных запросов отправляться: в этом случае перенаправление работает нормально (автоматически за которым следует браузер).
В противном случае вы могли бы определить, можете ли вы настроить сервер на отсутствие ответа 302 в случае запроса типа CORS, но вместо этого ответьте с помощью специального HTTP-кода, который вы можете идентифицировать на своем клиенте, чтобы включить перенаправление. содержимое ответа, чтобы ваш клиент выполнял его вручную.
Если у кого-то есть достоверная информация о том, почему это поведение, пожалуйста, укажите свой вклад: -)
Надеюсь, что это поможет.