Параметры CORB Запросы, заблокированные в Chrome 73 - PullRequest
Новая
       53

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

4 голосов
/ 10 апреля 2019

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

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

Я определил, что запросы к моему API успешно выполняются и что запрос OPTIONS перед полетом вызывает предупреждение в консоли.

Приложение, которое вызывает API, явно не делает запрос OPTIONS, скорее я понял, что браузер принудительно применяет его при отправке запроса из разных источников и автоматически выполняет браузер.

Я могу подтвердить, что в ответе на запрос OPTIONS не определен тип mime. Тем не менее, я немного запутался, так как я понимаю, что ответ OPTIONS - это только заголовки и не содержит тела. Я не понимаю, почему такой запрос требует определения типа mime.

enter image description here

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

enter image description here

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

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

1 Ответ

5 голосов
/ 12 апреля 2019

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

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

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

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

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

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

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

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

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

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

...