#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 выполняются успешно. Похоже, что запрос параметров на самом деле не блокируется?
Это вопрос из трех частей:
- Почему для запроса параметров требуется определение mime-типа, когда нет ответа тела?
- Каким должен быть mime-тип для запроса параметров, если обычный / текстовый не подходит? Могу ли я предположить, что application / json является правильным?
- Как мне настроить мой сервер 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
заголовка решили проблему.