Запросы параметров CORB заблокированы в Chrome 73

#google-chrome #cors #apache2 #cross-origin-read-blocking

#google-chrome #cors #apache2 #перекрестная блокировка чтения

Вопрос:

Похоже, что в недавнем выпуске Chrome (или, по крайней мере, в последнее время при вызовах моего API — не видел его до сегодняшнего дня) Google выдает предупреждения о блокировке запросов CORB.

Блокировка чтения из разных источников (CORB) заблокировала ответ из разных источников [домен] с типом MIME text / plain. См. https://www.chromestatus.com/feature/5629709824032768 для получения более подробной информации.

Я определил, что запросы к моему API выполняются успешно, и что предупреждение в консоли вызывает запрос ПАРАМЕТРОВ перед запуском.

Приложение, вызывающее API, явно не запрашивает параметры, скорее я понял, что это выполняется браузером при выполнении запроса из разных источников и выполняется браузером автоматически.

Я могу подтвердить, что в ответе на запрос ПАРАМЕТРОВ не определен mime-тип. Однако я немного сбит с толку, поскольку, насколько я понимаю, ответ OPTIONS — это только заголовки и не содержит тела. Я не понимаю, почему для такого запроса требуется определение mime-типа.

введите описание изображения здесь

Более того, в предупреждении консоли говорится, что запрос был заблокирован; однако различные запросы POST и GET выполняются успешно. Похоже, что запрос параметров на самом деле не блокируется?

введите описание изображения здесь

Это вопрос из трех частей:

  1. Почему для запроса параметров требуется определение mime-типа, когда нет ответа тела?
  2. Каким должен быть mime-тип для запроса параметров, если обычный / текстовый не подходит? Могу ли я предположить, что application / json является правильным?
  3. Как мне настроить мой сервер Apache2 на включение mime-типа для всех запросов параметров перед полетом?

Комментарии:

1. Предварительная настройка ПАРАМЕТРОВ выполняется успешно. Если бы это не удалось, браузер остановился бы прямо там и никогда больше не пытался выполнить ваш запрос POST. Тот факт, что вы видите запрос POST, указывает на то, что предварительная обработка прошла успешно. Запрос ПАРАМЕТРОВ не требует определения типа mime. В вопросе нет никаких указаний на то, что у вас вообще есть какие-либо проблемы с CORS. Вместо этого у вас проблема с CORB. Сообщение об ошибке, указанное в вопросе, указывает на то, что ваш код получает текстовый / простой ответ, но код пытается использовать этот ответ в некотором контексте, где браузер не ожидает использования текста / простого текста.

2. Вероятно, вы сможете получить лучшую помощь здесь, если обновите вопрос, добавив фрагмент вашего внешнего интерфейса, который показывает, как вы делаете запрос и как вы используете ответ. Например, вы можете получать ошибку CORB, потому что ваш код пытается проанализировать этот текст / простой ответ как JSON.

3. Правильно, как я уже отмечал, запрос ПАРАМЕТРОВ выполняется успешно, потому что запрос POST выполняется успешно. Вы также правы в том, что я тоже не думал, что для запроса ПАРАМЕТРОВ требуется mime-тип, но Chrome, похоже, думает, что это так? Вы также правы в том, что у меня нет проблемы с CORS, мой вопрос не о CORS, поэтому я не поднимаю его. Как вы можете видеть в примере ответа POST, я возвращаю соответствующий тип mime — предупреждение в Chrome относится к запросу OPTIONS, у которого нет mime-типа (потому что я считаю, что он не нужен). Я начинаю верить, что это ошибка в Chrome.

Ответ №1:

Я добрался до сути этих предупреждений CORB.

Проблема частично связана с моим использованием content-type-options: nosniff заголовка. Я установил этот заголовок, чтобы помешать браузеру пытаться перехватить сам тип содержимого, тем самым удалив обман типа mime, а именно с загруженными пользователем файлами, в качестве вектора атаки.

Другая часть этого связана с возвращаемым типом содержимого application/json;charset=utf-8 . Согласно документации Google, в нем отмечается:

Ответ, отправленный с заголовком ответа «X-Content-Type-Options: nosniff» и неправильным заголовком ответа «Content-Type», может быть заблокирован.

Исходя из этого, я решил дважды проверить сайт IANA на приемлемые типы носителей. К моему удивлению, я обнаружил, что ни charset один параметр не был фактически определен ни в одном RFC для типа application / json, и дополнительные примечания:

Для этой регистрации не определен параметр «charset». Добавление одного действительно не влияет на совместимых получателей.

Исходя из этого, я удалил кодировку из content-type: application/json и могу подтвердить, что предупреждения CORB остановлены в Chrome.

В заключение, похоже, что в недавнем выпуске Chrome Google решил начать более строго относиться к mime-типу, чем в прошлом.

Наконец, в качестве дополнительного примечания, причина, по которой все наши запросы приложений по-прежнему выполняются успешно, заключается в том, что, похоже, блокировка чтения из разных источников фактически не применяется в Chrome:

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

Комментарии:

1. Точно такие же ошибки здесь. Включали ли вы Content-Type: application / json в заголовки ответов запросов ПАРАМЕТРОВ? Я удалил кодировку из своих ответов, и я все еще получал эти предупреждения (мой API не предоставляет заголовок типа содержимого для запросов параметров)

2. В моих тестах использование application/json;charset=utf-8 в сравнении с использованием application/json в качестве типа содержимого не оказывает никакого влияния на предупреждающее сообщение CORB. Единственный способ, которым я смог удалить предупреждение, — это перестать возвращать content-type-options: nosniff заголовок для запросов параметров.

3. Я сделал небольшую тестовую утилиту доступной здесь: foobar.kytomaki.com/corb-test . Он отправляет POST-запрос в PHP-скрипт. По умолчанию скрипт возвращает nosniff заголовок только для запроса POST, и вы не должны видеть никаких предупреждений. При установке первого флажка заголовок также возвращается для запроса ПАРАМЕТРОВ, и вы должны увидеть предупреждение CORB. Второй флажок определяет, будет ли кодировка добавлена в конец типа содержимого, и для меня это, похоже, не имеет никакого значения.

Ответ №2:

Возникла та же проблема.

Проблема, с которой я столкнулся, была связана с тем, что API отвечал на предполетный 200 OK запрос, но был пустым ответом без Content-Length установленного заголовка.

Итак, либо изменение статуса ответа 204 No Content перед выполнением, либо простая установка Content-Length: 0 заголовка решили проблему.