Когда браузеры отправляют заголовок Origin? Когда браузеры устанавливают источник в null?

Как вы можете видеть из этого потока Bugzilla (а также), Firefox не всегда отправляет заголовок Origin в запросах POST. RFC заявляет, что его не следует отправлять в определенных неопределенных контекстах, "чувствительных к конфиденциальности". Mozilla определяет эти контексты здесь.

Я хотел бы знать, являются ли это единственными ситуациями, когда Firefox не отправляет заголовок Origin. Насколько я могу судить, он также не будет отправлять его в POST-запросах между источниками (хотя Chrome и IE будут), но я не могу подтвердить это в документации. Это где-то перечислено, что я скучаю?

Ответы

Ответ 1

Насколько требуют спецификации, вопрос выше должен быть разделен на пару ответов:

  • Когда браузеры должны отправить заголовок Origin
  • Когда браузеры должны внутренне установить происхождение значение Thatll получить сериализации в null

Я сомневаюсь, что то, что требуется Firefox для этого (где оно отличается от спецификации), перечислено. Но что касается перечисления спецификационных требований, то здесь они, во всех подробностях, разделены на две части:

Когда браузеры должны отправить заголовок Origin

Ответ на вопрос Когда браузеры должны отправлять заголовок Origin? is: заголовок Origin отправляется только для любого запроса, который спецификация Fetch определяет как запрос CORS:

CORS-запрос - это HTTP-запрос с заголовком Origin. Он не может быть надежно идентифицирован как участвующий в протоколе CORS, поскольку заголовок Origin также включен для всех запросов, метод которых не является ни GET ни HEAD.

Фактический оператор в спецификации Fetch, который требует, чтобы браузеры отправляли заголовок Origin для всех запросов, чей метод не является ни GET ни HEAD:

Если установлен флаг CORS или метод httpRequests не является ни GET ни HEAD, то добавьте Origin/httpRequests origin, serialized и UTF-8 закодированный в список заголовков httpRequests.

Так что требует браузеры для отправки Origin для всех POST запросов, в том числе одного источника POST (который по определению в Fetch на самом деле являются "CORS запросы" -Еще хотя Theyre же происхождения).

Примечание. Выше описано, как спецификация Fetch в настоящее время определяет требования, в связи с изменением, внесенным в спецификацию на 2016-12-09. До тех пор требования были другими:

  • ранее не Origin было отправлено на POST-же происхождение
  • ранее Origin было отправлено для отправки POST из <form> (без CORS)

Поэтому я думаю, что поведение Firefox, описанное в этом вопросе, соответствует тому, что ранее требовалось для спецификации, а не тому, что требует спецификация в настоящее время.

Другими случаями, когда браузеры должны отправлять заголовок Origin являются любые случаи, когда запрос выполняется с установленным "флагом CORS", который, насколько запросы HTTP (S) , websocket, когда режим запроса - navigate, websocket, same-origin или no-cors.

XHR всегда устанавливает режим на cors. Но с помощью API Fetch эти режимы запросов можно установить в поле mode аргумента init-object метода fetch(…):

fetch("http://example.com", { mode: 'no-cors' }) // no Origin will be sent

Наряду с этим для любого элемента с атрибутом crossorigin (он же "атрибут установки CORS) спецификация HTML требует, чтобы браузеры установили режим запроса cors (и отправили заголовок Origin).

В противном случае для любых элементов, которые инициируют запросы (скрипты, таблицы стилей, изображения, медиа-элементы), режим для запросов по умолчанию равен no-cors, что означает, что заголовок Origin для них не отправляется.

Так что выше приведены подробности об условиях, при которых браузеры отправляют заголовок Origin.

Следующая часть ответа о том, когда исходное значение будет установлено равным null.

Когда браузеры должны установить origin на значение, которое будет сериализовано как null

Отдельно от требований, когда браузеры должны отправлять заголовок Origin есть требования, когда браузеры должны устанавливать источник в null, которые определены в следующих спецификациях:

Спецификация HTML использует термин непрозрачное происхождение и говорит следующее:

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

Другими словами, везде, где спецификация HTML говорит о непрозрачном происхождении, вы можете перевести это на null.

Спецификация HTML требует, чтобы браузеры устанавливали непрозрачный источник или уникальный источник в следующих случаях:

  1. Изображения перекрестного происхождения (включая элементы img перекрестного происхождения)
  2. Мультимедийные данные о происхождении (включая video и audio)
  3. Любой документ, сгенерированный из data: URL
  4. Любой iframe с атрибутом sandbox который не содержит значение allow-same-origin
  5. Любой документ, программно созданный с использованием createDocument() и т.д.
  6. Любой документ, который не имеет контекста просмотра создателя
  7. Ответы, которые являются ошибками сети
  8. Должна ли политика безопасности контента блокировать ответ навигации на запрос навигации типа от источника в цели? Алгоритм возвращает Заблокированный при выполнении в ответе навигации

Спецификация Fetch требует, чтобы браузеры устанавливали в качестве источника "глобально уникальный идентификатор" (что в основном означает то же самое, что и "непрозрачное происхождение", что в основном означает null …) в одном случае:

  1. Перенаправляет через происхождение

Спецификация URL требует, чтобы браузеры устанавливали непрозрачный источник в следующих случаях:

  1. Для blob: URL
  2. Для file: URL
  3. Для любых других URL, чья схема не относится к http, https, ftp, ws, wss или gopher.

Но его важно понимать, что только потому, что браузер внутренне установлен непрозрачный происхождение, по существу null -Вота обязательно не означает, что браузер отправит Origin заголовок. Так что смотрите первую часть этого ответа, чтобы узнать, когда браузеры должны отправлять заголовок Origin.