Запросы CORB OPTIONS заблокированы в Chrome 73
Похоже, что в недавнем выпуске Chrome (или, по крайней мере, недавно при вызовах моего API — не видел его до сегодняшнего дня) Google выдает предупреждения о блокировке запросов CORB.
Cross-Origin Read Blocking (CORB) blocked cross-origin response [domain] with MIME type text/plain. See https://www.chromestatus.com/feature/5629709824032768 for more details.
Я определил, что запросы к моему API выполняются успешно, и что это предварительный запрос OPTIONS вызывает предупреждение в консоли.
Приложение, которое вызывает API, явно не делает запрос OPTIONS, скорее, я понял, что это принудительно применяется браузером при выполнении запроса между источниками и выполняется браузером автоматически.
Я могу подтвердить, что ответ на запрос OPTIONS не имеет определенного типа mime. Однако я немного сбит с толку, поскольку, насколько я понимаю, ответ OPTIONS представляет собой только заголовки и не содержит тела. Я не понимаю, почему такой запрос требует определения MIME-типа.
Более того, в предупреждении консоли говорится, что запрос заблокирован; тем не менее, различные запросы POST и GET выполняются успешно. Получается, что запрос OPTIONS на самом деле не блокируется?
Это вопрос из трех частей:
- Почему запрос OPTIONS требует определения типа mime, когда нет ответа тела?
- Каким должен быть тип mime для запроса OPTIONS, если обычный/текст не подходит? Могу ли я предположить, что приложение/json является правильным?
- Как мне настроить сервер Apache2, чтобы он включал mime-тип для всех предварительных запросов OPTIONS?
Вероятно, здесь вам помогут лучше, если вы обновите вопрос, добавив фрагмент кода вашего внешнего интерфейса, который показывает, как вы делаете запрос и как вы получаете ответ. Например, вы можете получить ошибку CORB, потому что ваш код пытается разобрать этот текстовый/обычный ответ как JSON.
Правильно, как я заметил, запрос OPTIONS выполнен успешно, потому что запрос POST выполнен успешно. Вы также правы в том, что я тоже не думал, что для запроса OPTIONS нужен MIME-тип, но Chrome, похоже, так думает? Вы также правы в том, что у меня нет проблемы с CORS, мой вопрос не о CORS, поэтому я его не поднимаю. Как вы можете видеть в примере ответа POST, я возвращаю соответствующий MIME-тип — предупреждение в Chrome относится к запросу OPTIONS, который не имеет MIME-типа (потому что я считаю, что он не нужен). Я начинаю верить, что это ошибка в Chrome.
Ответы 2
Я добрался до сути этих предупреждений CORB.
Проблема частично связана с тем, что я использую заголовок content-type-options: nosniff. Я установил этот заголовок, чтобы запретить браузеру пытаться пронюхать сам контент-тип, тем самым удаляя уловки mime-типа, а именно с файлами, загруженными пользователем, в качестве вектора атаки.
Другая часть этого связана с возвращаемым типом контента application/json;charset=utf-8. В документации Google отмечается:
A response served with a "X-Content-Type-Options: nosniff" response header and an incorrect "Content-Type" response header, may be blocked.
Исходя из этого, я решил дважды проверить сайт IANA на допустимые типы носителей. К моему удивлению, я обнаружил, что ни один параметр charset не был определен ни в одном RFC для типа приложение/json, и дополнительные примечания:
No "charset" parameter is defined for this registration. Adding one really has no effect on compliant recipients.
Исходя из этого, я удалил кодировку из content-type: application/json и могу подтвердить, что предупреждения CORB остановлены в Chrome.
В заключение, похоже, что в недавнем выпуске Chrome Google решил начать относиться к MIME-типу более строго, чем в прошлом.
Наконец, в качестве примечания, причина, по которой все запросы нашего приложения по-прежнему выполняются успешно, заключается в том, что в Chrome отображается блокировка чтения из разных источников на самом деле не соблюдается:
In most cases, the blocked response should not affect the web page's behavior and the CORB error message can be safely ignored.
Здесь точно такие же ошибки. Вы включили Content-Type: application/json в заголовки ответов запросов OPTIONS? Я удалил кодировку из своих ответов, и я все еще получаю эти предупреждения (мой API не предоставляет заголовок Content-Type для запросов OPTIONS)
В моих тестах использование application/json;charset=utf-8 по сравнению с использованием application/json в качестве типа контента не оказывает никакого влияния на предупреждающее сообщение CORB. Единственный способ, которым я смог удалить предупреждение, — это прекратить возвращать заголовок content-type-options: nosniff для запросов OPTIONS.
Я сделал небольшую тестовую утилиту, доступную здесь: foobar.kytomaki.com/corb-test. Он делает POST-запрос к PHP-скрипту. По умолчанию скрипт возвращает заголовок nosniff только для запроса POST, и вы не должны видеть никаких предупреждений. При установке первого флажка заголовок также возвращается для запроса OPTIONS, и вы должны увидеть предупреждение CORB. Второй флажок определяет, будет ли кодировка добавляться в конец типа содержимого, и для меня это не имеет никакого значения.
Была такая же проблема.
Проблема, с которой я столкнулся, была связана с тем, что API отвечал на предварительную проверку с помощью 200 OK, но был пустым ответом без установленного заголовка Content-Length.
Таким образом, либо изменение статуса ответа предварительной проверки на 204 No Content, либо просто установка заголовка Content-Length: 0 решили проблему.
Предварительная проверка OPTIONS проходит успешно. В случае сбоя браузер сразу же остановится и больше не будет пытаться выполнить ваш POST-запрос. Тот факт, что вы видите запрос POST, указывает на то, что предварительная проверка прошла успешно. Запрос OPTIONS не требует определения MIME-типа. В вопросе нет никаких указаний на то, что у вас есть какие-либо проблемы с CORS. Вместо этого у вас есть проблема CORB. Сообщение об ошибке, указанное в вопросе, указывает на то, что ваш код получает текстовый/простой ответ, но код пытается использовать этот ответ в каком-то контексте, где браузер не ожидает использования текста/простого текста.