RFC 7233 | Протокол передачи гипертекста (HTTP/1.1): запросы диапазона

Аннотация

Протокол передачи гипертекста (HTTP) — это протокол уровня приложений без сохранения состояния для распределенных, совместных гипертекстовых информационных систем. В этом документе определяются запросы диапазона и правила построения и объединения ответов на эти запросы.

Скачать оригинальную версию документа на английском языке RFC 7233 PDF

 

Оглавление

1. Введение
1.1. Соответствие и обработка ошибок
1.2. Синтаксическая нотация
2. Единицы измерения диапазона
2.1. Диапазоны байтов
2.2. Другие Единицы Диапазона
2.3. Заголовок Accept-Ranges
3. Диапазон запросов
3.1. Заголовок Range
3.2. Заголовок If-Range
4. Ответы на запрос диапазона
4.1. Код 206 Частичное содержание
4.2. Заголовок Content-Range
4.3. Объединение диапазонов
4.4. Код 416 Неудовлетворительный диапазон
5. Соображения IANA
5.1. Регистр единиц измерения дальности
5.1.1. Процедура
5.1.2. Регистрация
5.2. Регистрация кода статуса
5.3. Регистрация поля заголовка
5.4. Регистрация интернет-медиа типа
5.4.1. Тип интернет-медиа «multipart/byteranges»
6. Вопросы безопасности
6.1. Атаки типа «отказ в обслуживании» с использованием диапазона
7. Благодарности
8. Ссылки
8.1. Нормативные ссылки
8.2. Информационные ссылки
Приложение А. Тип интернет-медиа «multipart/byteranges»
Приложение B. Изменения по сравнению с RFC 2616
Приложение C. Импортированный ABNF
Приложение D. Собранный ABNF
Индекс
Адреса авторов

 

1. Введение

Клиенты по протоколу гипертекстовой передачи (HTTP) часто сталкиваются с прерывистой передачей данных в результате отмененных запросов или разорванных соединений. Когда клиент сохранил частичное представление, желательно запросить остаток этого представления в последующем запросе, а не передавать полное представление. Аналогичным образом, устройства с ограниченным локальным хранилищем могут выиграть от возможности запрашивать только подмножество более крупного представления, такого как одна страница очень большого документа или размеры встроенного изображения.

Этот документ определяет запросы диапазона HTTP/1.1, частичные ответы и мультимедийный тип «multipart/byteranges». Запросы диапазона являются ОПЦИОНАЛЬНОЙ функцией HTTP, разработанной так, чтобы получатели, не реализующие эту функцию (или не поддерживающие ее для целевого ресурса), могли отвечать, как если бы это был обычный запрос GET, не влияя на совместимость. Частичные ответы обозначаются отдельным кодом состояния, чтобы их нельзя было принять за полные ответы кешами, которые могут не реализовывать эту функцию.

Хотя механизм запроса диапазона разработан для учета расширяемых типов диапазона, эта спецификация определяет только запросы для байтовых диапазонов.

1.1. Соответствие и обработка ошибок

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

Критерии соответствия и соображения, касающиеся обработки ошибок, определены в разделе 2.5 [RFC7230 #].

1.2. Синтаксическая нотация

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) [RFC5234 #] с расширением списка, определенным в разделе 7 [RFC7230 #], который позволяет компактно определять списки, разделенные запятыми, используя оператор решётки «#» (аналогично как оператор звёздочка ‘*’ указывает на повторение). Приложение C описывает правила, импортированные из других документов. В приложении D показана собранная грамматика, в которой все операторы списка расширены до стандартной записи ABNF.

 

2. Единицы измерения диапазона

Представление может быть разделено на поддиапазоны в соответствии с различными структурными единицами, в зависимости от структуры, присущей типу носителя представления. Эта «единица измерения диапазона» (range unit) используется в поле заголовка ответа Accept-Ranges (раздел 2.3) для объявления поддержки запросов диапазона, в поле заголовка запроса Range (раздел 3.1) для разграничения частей представления, которые запрашиваются, и в Content-Range заголовка полезной нагрузки (раздел 4.2), описывающее, какая часть представления переносится.

range-unit = bytes-unit / other-range-unit

2.1. Диапазоны байтов

Поскольку данные представления передаются в полезных нагрузках в виде последовательности октетов, диапазон байтов является значимой субструктурой для любого представления, передаваемого по HTTP (Раздел 3 [RFC7231 #]). Единица диапазона «байты» (bytes) определена для выражения поддиапазонов последовательности октетов данных.

bytes-unit = "bytes"

Запрос диапазона байтов может указывать один диапазон байтов или набор диапазонов в одном представлении.

byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT

Значение «first-byte-pos» в спецификации «byte-range-spec» даёт смещение байта первого байта в диапазоне. Значение «last-byte-pos» дает смещение байта последнего байта в диапазоне; то есть указанные байтовые позиции включительно. Смещения байтов начинаются с нуля.

Примеры значений спецификаторов байтовых диапазонов:

• Первые 500 байтов (смещение байтов 0-499 включительно):

байт = 0-499

• Вторые 500 байтов (смещение байтов 500-999 включительно):

байт = 500-999

Спецификация «byte-range-spec» недопустима, если присутствует значение «last-byte-pos» и меньше, чем значение «first-byte-pos«.

Клиент может ограничить количество запрошенных байтов, не зная размера выбранного представления. Если значение «last-byte-pos» отсутствует или если значение больше или равно текущей длине данных представления, диапазон байтов интерпретируется как остаток представления (т. е. Сервер заменяет значение «last-byte-pos» со значением, которое на единицу меньше текущей длины выбранного представления).

Клиент может запросить последние N байтов выбранного представления, используя «suffix-byte-range-spec«.

suffix-byte-range-spec = "-" suffix-length
suffix-length = 1*DIGIT

Если выбранное представление короче указанной длины суффикса, используется все представление.

Дополнительные примеры, предполагающие представление длины 10000:

• Финальные 500 байтов (смещение байтов 9500-9999 включительно):

байт = -500

Или же:

байт = 9500-

• Только первый и последний байты (байты 0 и 9999):

байт = 0-0, -1

• o Другие действительные (но не канонические) спецификации второго 500

байт (смещение байтов 500-999 включительно):

байт = 500-600,601-999

байт = 500-700,601-999

Если допустимый набор диапазонов байтов (byte-range-set) включает в себя, по крайней мере, одну спецификацию диапазона байтов (byte-range-spec) с первым байтовым положением (first-byte-pos), которое меньше текущей длины представления, или, по крайней мере, одну спецификацию суффикса байта (suffix-byte-range-spec) с не нулевой длиной суффикса, тогда набор диапазонов байтов (byte-range-set) выполним. В противном случае набор диапазонов байтов (byte-range-set) является неудовлетворительным.

В синтаксисе байтового диапазона (byte-range) элементы first-byte-pos, last-byte-pos и suffix-length выражаются в виде десятичного числа октетов. Поскольку нет предопределенного ограничения на длину полезной нагрузки, получатели ДОЛЖНЫ предвидеть потенциально большие десятичные цифры и предотвращать ошибки синтаксического анализа из-за переполнения целочисленных преобразований.

 

2.2. Другие Единицы Диапазона

Единицы измерения дальности предназначены для расширения. Новые единицы измерения дальности должны быть зарегистрированы в IANA, как определено в разделе 5.1.

other-range-unit = token

 

2.3. Заголовок Accept-Ranges

Поле заголовка «Accept-Ranges» позволяет серверу указать, что он поддерживает запросы диапазона для целевого ресурса.

Accept-Ranges = acceptable-ranges
acceptable-ranges = 1#range-unit / "none"

Исходный сервер, который поддерживает запросы диапазона байтов для данного целевого ресурса, МОЖЕТ отправить

Accept-Ranges: bytes

чтобы указать, какие единицы измерения диапазона поддерживаются. Клиент МОЖЕТ генерировать запросы диапазона, не получив это поле заголовка для задействованного ресурса. Единицы измерения диапазона определены в разделе 2.

Сервер, который не поддерживает какой-либо запрос диапазона для целевого ресурса, МОЖЕТ отправить

Accept-Ranges: none

советовать клиенту не пытаться запросить диапазон.

 

3. Диапазон запросов

3.1. Заголовок Range

Поле заголовка «Range» в запросе GET изменяет семантику метода, чтобы запросить передачу только одного или нескольких поддиапазонов выбранных данных представления, а не всех выбранных данных представления.

Range = byte-ranges-specifier / other-ranges-specifier
other-ranges-specifier = other-range-unit "=" other-range-set
other-range-set = 1*VCHAR

Сервер МОЖЕТ игнорировать поле заголовка Range. Однако исходные серверы и промежуточные кэши должны поддерживать байтовые диапазоны, когда это возможно, поскольку Range поддерживает эффективное восстановление после частично неудачных передач и частичного извлечения больших представлений. Сервер ДОЛЖЕН игнорировать поле заголовка Range, полученное с помощью метода запроса, отличного от GET.

Исходный сервер ДОЛЖЕН игнорировать поле заголовка Range, которое содержит единицу измерения, которую он не понимает. Прокси-сервер МОЖЕТ отбросить поле заголовка Range, которое содержит единицу измерения диапазона, которую он не понимает.

Сервер, поддерживающий запросы диапазона, МОЖЕТ игнорировать или отклонять поле заголовка Range, состоящее из более чем двух перекрывающихся диапазонов, или набора множества небольших диапазонов, которые не перечислены в порядке возрастания, поскольку оба являются признаками либо неисправного клиента, либо преднамеренной атаки типа «отказ в обслуживании» (denial-of-service) (раздел 6.1). Клиенту НЕ СЛЕДУЕТ запрашивать несколько диапазонов, которые по своей природе менее эффективны для обработки и передачи, чем один диапазон, охватывающий одни и те же данные.

Клиент, запрашивающий несколько диапазонов, ДОЛЖЕН перечислять эти диапазоны в порядке возрастания (порядок, в котором они обычно принимаются в полном представлении), если нет особой необходимости запрашивать более позднюю часть ранее. Например, пользовательскому агенту, обрабатывающему большое представление с внутренним каталогом деталей, может потребоваться сначала запросить более поздние детали, особенно если представление состоит из страниц, хранящихся в обратном порядке, и пользовательский агент желает передавать по одной странице за раз.

Поле заголовка диапазона Range оценивается после оценки полей заголовка предварительного условия, определенных в [RFC7232 #], и только в том случае, если результатом отсутствия поля заголовка Range будет ответ 200 (ОК). Другими словами, Range игнорируется, когда условный GET приводит к ответу 304 (не изменен).

Поле заголовка If-Range (раздел 3.2) можно использовать в качестве предварительного условия для применения поля заголовка Range.

Если все предварительные условия выполняются, сервер поддерживает поле заголовка Range для целевого ресурса, и указанные диапазоны являются допустимыми и выполнимыми (как определено в разделе 2.1), сервер ДОЛЖЕН отправить ответ 206 (частичное содержимое) с полезной нагрузкой, содержащей одно или несколько частичных представлений, которые соответствуют требуемым диапазонам, как определено в разделе 4.

Если все предварительные условия выполняются, сервер поддерживает поле заголовка Range для целевого ресурса, и указанные диапазоны являются недопустимыми или неудовлетворительными, сервер ДОЛЖЕН отправить ответ 416 (Range Not Satisfiable).

 

3.2. Заголовок If-Range

Если клиент имеет частичную копию представления и хочет иметь актуальную копию всего представления, он может использовать поле заголовка Range с условным GET (используя один или оба из If-Unmodified-Since и If -Match.) Однако, если предварительное условие не выполняется из-за того, что представление было изменено, клиент должен был бы сделать второй запрос для получения всего текущего представления.

Поле заголовка «If-Range» позволяет клиенту «замкнуть» (short-circuit) второй запрос. Неофициально, его значение таково: если представление не изменилось, пришлите мне часть (части), которую я запрашиваю в Range; в противном случае пришлите мне все представление.

If-Range = entity-tag / HTTP-date

Клиент НЕ ДОЛЖЕН генерировать поле заголовка If-Range в запросе, который не содержит поле заголовка Range. Сервер ДОЛЖЕН игнорировать поле заголовка If-Range, полученное в запросе, который не содержит поле заголовка Range. Исходный сервер ДОЛЖЕН игнорировать поле заголовка If-Range, полученное в запросе целевого ресурса, который не поддерживает запросы Range.

Клиент НЕ ДОЛЖЕН генерировать поле заголовка If-Range, содержащее тег объекта, который помечен как слабый. Клиент НЕ ДОЛЖЕН генерировать поле заголовка If-Range, содержащее HTTP-дату, если только у клиента нет тега сущности для соответствующего представления, а дата не является строгим валидатором в смысле, определенном в разделе 2.2.2 [RFC7232 #].

Сервер, который оценивает предварительное условие If-Range, ДОЛЖЕН использовать функцию строгого сравнения при сравнении тегов объекта (раздел 2.3.2 [RFC7232 #]) и ДОЛЖЕН оценивать условие как ложное, если предусмотрен валидатор HTTP-даты, который не является сильным валидатор в смысле, определенном в разделе 2.2.2 [RFC7232 #]. Действительный тэг объекта можно отличить от действительной даты HTTP, проверяя первые два символа DQUOTE.

Если валидатор, указанный в поле заголовка If-Range, совпадает с текущим валидатором для выбранного представления целевого ресурса, то сервер ДОЛЖЕН обработать поле заголовка Range в соответствии с запросом. Если валидатор не совпадает, сервер ДОЛЖЕН игнорировать поле заголовка Range. Обратите внимание, что это сравнение по точному совпадению, в том числе когда валидатор является HTTP-датой, отличается от сравнения «раньше или равно» (earlier than or equal to), используемого при оценке условного условия If-Unmodified-Since.

 

4. Ответы на запрос диапазона

4.1. Код 206 Частичное содержание

Код состояния 206 (частичное содержимое) указывает, что сервер успешно выполняет запрос диапазона для целевого ресурса, передав одну или несколько частей выбранного представления, которые соответствуют выполнимым диапазонам, найденным в поле заголовка диапазона запроса (раздел 3.1).

Если передается одна часть, сервер, генерирующий ответ 206, ДОЛЖЕН сгенерировать поле заголовка Content-Range, описывающее, какой диапазон выбранного представления заключен, и полезную нагрузку, состоящую из диапазона. Например:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
... 26012 bytes of partial image data ...

Если передается несколько частей, сервер, генерирующий ответ 206, ДОЛЖЕН сгенерировать полезную нагрузку «multipart/byteranges», как определено в Приложении A, и поле заголовка Content-Type, содержащее мультимедийный тип multipart/byteranges и его требуемый граничный параметр. Чтобы избежать путаницы с ответами из одной части, сервер НЕ ДОЛЖЕН генерировать поле заголовка Content-Range в разделе заголовка HTTP ответа из нескольких частей (вместо этого это поле будет отправлено в каждой части).

В пределах области заголовка каждой части тела в полезной нагрузке, состоящей из нескольких частей, сервер ДОЛЖЕН генерировать поле заголовка Content-Range, соответствующее диапазону, заключенному в этой части тела. Если выбранное представление имело бы поле заголовка Content-Type в ответе 200 (ОК), сервер ДОЛЖЕН генерировать это же поле Content-Type в области заголовка каждой части тела. Например:

HTTP/1.1 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Length: 1741
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 500-999/8000

...the first range...
--THIS_STRING_SEPARATES
Content-Type: application/pdf
Content-Range: bytes 7000-7999/8000

...the second range
--THIS_STRING_SEPARATES--

Когда запрашивается несколько диапазонов, сервер МОЖЕТ объединить любой из диапазонов, которые перекрываются или разделяются промежутком, который меньше, чем издержки отправки нескольких частей, независимо от порядка, в котором соответствующая спецификация диапазона байтов появилась в полученное поле заголовка диапазона. Поскольку типичные издержки между частями полезной нагрузки multipart/byteranges составляют около 80 байтов, в зависимости от типа носителя выбранного представления и выбранной длины граничного параметра, может быть менее эффективно передавать много небольших непересекающихся частей, чем передавать все выбранные представление.

Сервер НЕ ДОЛЖЕН генерировать много-частный ответ на запрос для одного диапазона, так как клиент, который не запрашивает несколько частей, может не поддерживать много-частные ответы. Однако сервер МОЖЕТ генерировать полезную нагрузку из нескольких multipart/byteranges только с одной частью тела, если было запрошено несколько диапазонов, и только один диапазон был признан удовлетворительным или после объединения остался только один диапазон. Клиент, который не может обработать ответ multipart/byteranges, НЕ ДОЛЖЕН генерировать запрос, который запрашивает несколько диапазонов.

Когда генерируется полезная нагрузка много-частичного ответа, сервер ДОЛЖЕН отправить части в том же порядке, в котором соответствующая спецификация диапазона байтов появилась в полученном поле заголовка Range, за исключением тех диапазонов, которые считались неудовлетворительными или были объединены в другие диапазоны. Клиент, который получает составной ответ, ДОЛЖЕН проверить поле заголовка Content-Range, присутствующее в каждой части тела, чтобы определить, какой диапазон содержится в этой части тела; клиент не может рассчитывать на получение тех же диапазонов, которые он запрашивал, или того же порядка, который он запрашивал.

Когда генерируется ответ 206, сервер ДОЛЖЕН генерировать следующие поля заголовка, в дополнение к тем, которые требуются выше, если бы поле было отправлено в ответе 200 (ОК) на тот же запрос: Date, Cache-Control, ETag, Expires, Content-Location и Vary.

Если 206 генерируется в ответ на запрос с полем заголовка If-Range, отправителю НЕ СЛЕДУЕТ генерировать другие поля заголовка представления помимо тех, которые требуются выше, поскольку считается, что у клиента уже есть предыдущий ответ, содержащий эти поля заголовка. В противном случае отправитель ДОЛЖЕН сгенерировать все поля заголовка представления, которые были бы отправлены в ответе 200 (ОК) на тот же запрос.

Ответ 206 кэшируется по умолчанию; то есть, если иное не указано в явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

 

4.2. Заголовок Content-Range

Поле заголовка «Content-Range» отправляется в единственном ответе части 206 (Частичное содержимое), чтобы указать частичный диапазон выбранного представления, заключенного в качестве полезной нагрузки сообщения, отправленного в каждой части ответа из множества частей 206, чтобы указать диапазон, заключенный в каждой части тела, и отправил 416 (диапазон не удовлетворяется) ответов, чтобы предоставить информацию о выбранном представлении.

Content-Range = byte-content-range / other-content-range

byte-content-range = bytes-unit SP ( byte-range-resp / unsatisfied-range )

byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range = first-byte-pos "-" last-byte-pos
unsatisfied-range = "*/" complete-length

complete-length = 1*DIGIT

other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR

Если ответ 206 (частичное содержимое) содержит поле заголовка Content-Range с единицей измерения диапазона (раздел 2), которую получатель не понимает, получатель НЕ ДОЛЖЕН пытаться рекомбинировать его с сохраненным представлением. Прокси, который получает такое сообщение, ДОЛЖЕН переслать его в нисходящем направлении.

Для диапазонов байтов отправителю СЛЕДУЕТ указывать полную длину представления, из которого был извлечен диапазон, если только полная длина неизвестна или ее трудно определить. Символ звездочки («*») вместо полной длины указывает, что длина представления была неизвестна при создании поля заголовка.

Следующий пример иллюстрирует, когда отправителю известно, что полная длина выбранного представления составляет 1234 байта:

Content-Range: bytes 42-1233/1234

и этот второй пример иллюстрирует, когда полная длина неизвестна:

Content-Range: bytes 42-1233/*

Значение поля Content-Range недопустимо, если оно содержит byte-range-resp, у которого значение last-byte-pos меньше, чем его значение first-byte-pos, или значение полной длины меньше или равно его last-byte-pos. Получатель недопустимого диапазона содержимого НЕ ДОЛЖЕН пытаться рекомбинировать полученный контент с сохраненным представлением.

Сервер, генерирующий 416 (Range Not Satisfiable) ответ на запрос диапазона байтов, ДОЛЖЕН отправить поле заголовка Content-Range со значением неудовлетворенного диапазона, как в следующем примере:

Content-Range: bytes */1234

Полная длина в ответе 416 указывает текущую длину выбранного представления.

Поле заголовка Content-Range не имеет значения для кодов состояния, которые явно не описывают его семантику. Для этой спецификации только коды состояния 206 (частичное содержимое) и 416 (диапазон не удовлетворяются) описывают значение для диапазона содержимого Content-Range.

Ниже приведены примеры значений Content-Range, в которых выбранное представление содержит в общей сложности 1234 байта:

• Первые 500 байтов:

Диапазон содержимого: байты 0-499 / 1234

• Вторые 500 байтов:

Диапазон содержимого: байты 500-999 / 1234

• Все, кроме первых 500 байтов:

Диапазон содержимого: байты 500-1233 / 1234

• Последние 500 байтов:

Диапазон содержимого: байты 734-1233 / 1234

 

 

4.3. Объединение диапазонов

Ответ может передавать только поддиапазоном представления, если соединение преждевременно закрыто или если в запросе используется одна или несколько спецификаций диапазона. После нескольких таких передач клиент мог получить несколько диапазонов одного и того же представления. Эти диапазоны могут быть безопасно объединены только в том случае, если все они имеют один и тот же строгий валидатор (раздел 2.1 [RFC7232 #]).

Клиент, получивший несколько частичных ответов на запросы GET на целевом ресурсе, МОЖЕТ объединить эти ответы в более широкий непрерывный диапазон, если они совместно используют один и тот же сильный валидатор.

Если самый последний ответ является неполным 200 (ОК) ответом, то поля заголовка этого ответа используются для любого комбинированного ответа и заменяют поля соответствующих сохраненных ответов.

Если самый последний ответ представляет собой ответ 206 (частичное содержимое), и по меньшей мере один из соответствующих сохраненных ответов является 200 (ОК), тогда поля заголовка комбинированного ответа состоят из самых последних полей заголовка ответа 200. Если все соответствующие сохраненные ответы являются 206 ответами, то сохраненный ответ с самыми последними полями заголовка используется в качестве источника полей заголовка для комбинированного ответа, за исключением того, что клиент ДОЛЖЕН использовать другие поля заголовка, предоставленные в новом ответе, кроме из Content-Range, чтобы заменить все экземпляры соответствующих полей заголовка в сохраненном ответе.

Тело комбинированного ответного сообщения состоит из объединения диапазонов частичного содержимого в новом ответе и каждом из выбранных ответов. Если объединение состоит из всего диапазона представления, тогда клиент ДОЛЖЕН обработать комбинированный ответ, как если бы он был полным 200 (ОК) ответом, включая поле заголовка Content-Length, которое отражает полную длину. В противном случае клиент ДОЛЖЕН обработать набор непрерывных диапазонов как один из следующих: неполный ответ 200 (ОК), если комбинированный ответ является префиксом представления, один ответ 206 (частичное содержимое), содержащий тело, состоящее из нескольких «multipart/byteranges«, или несколько ответов 206 (частичное содержимое), каждое с одним непрерывным диапазоном, указанным в поле заголовка Content-Range.

 

4.4. Код 416 Неудовлетворительный диапазон

Код состояния 416 (Range Not Satisfiable) указывает, что ни один из диапазонов в поле заголовка Range запроса (раздел 3.1) не перекрывает текущее пространство выбранного ресурса или что запрошенный набор диапазонов был отклонен из-за недопустимых диапазонов или чрезмерного запроса малых или перекрывающихся диапазонов.

Для байтовых диапазонов отказ от перекрытия текущего пространства означает, что первый-байтовый столб всех значений спецификации байтового диапазона был больше, чем текущая длина выбранного представления. Когда этот код состояния генерируется в ответ на запрос диапазона байтов, отправителю СЛЕДУЕТ генерировать поле заголовка Content-Range, определяющее текущую длину выбранного представления (раздел 4.2).

Например:

HTTP/1.1 416 Range Not Satisfiable
Date: Fri, 20 Jan 2012 15:41:54 GMT
Content-Range: bytes */47022

Примечание. Поскольку серверы могут игнорировать Range, многие реализации просто ответят всем выбранным представлением в ответе 200 (ОК). Это отчасти потому, что большинство клиентов готовы получить 200 (ОК) для выполнения задачи (хотя и менее эффективно), а отчасти потому, что клиенты могут не прекратить делать недопустимый частичный запрос, пока они не получат полное представление. Таким образом, клиенты не могут зависеть от получения ответа 416 (диапазон не удовлетворен), даже если он наиболее уместен.

 

5. Соображения IANA

5.1. Регистр единиц измерения дальности

«Реестр единиц измерения диапазона HTTP» определяет пространство имен для имен единиц измерения диапазона и ссылается на их соответствующие спецификации. Реестр создан и в настоящее время поддерживается по адресу <http://www.iana.org/assignments/http-parameters>.

5.1.1. Процедура

Регистрация HTTP Range Unit ДОЛЖНА включать следующие поля:

• Имя
• Описание
• Указатель на текст спецификации

Значения, которые необходимо добавить в это пространство имен, требуют проверки IETF (см. [RFC5226 #], раздел 4.1).

5.1.2. Регистрация

Начальный регистр единиц измерения содержит следующие регистрации:

Таблица

Контроллер изменений: «IETF (iesg@ietf.org) — Целевая рабочая группа по Интернету».

 

5.2. Регистрация кода статуса

«Реестр кодов состояния протокола передачи гипертекста (HTTP)», расположенный по адресу <http://www.iana.org/assignments/http-status-codes>, был обновлен и теперь включает следующие регистрации:

Таблица

 

5.3. Регистрация поля заголовка

Поля заголовка HTTP регистрируются в реестре «Заголовки сообщений», который ведется по адресу <http://www.iana.org/assignments/message-headers/>.

В этом документе определены следующие поля заголовка HTTP, поэтому соответствующие записи реестра были обновлены в соответствии с постоянной регистрацией ниже (см. [BCP90]):

Таблица

Контроллер изменений: «IETF (iesg@ietf.org) — Целевая рабочая группа по Интернету».

 

5.4. Регистрация интернет-медиа типа

IANA ведет реестр типов интернет-медиа [BCP13] по адресу <http://www.iana.org/assignments/media-types>.

Этот документ служит спецификацией для типа интернет-медиа «multipart / byteranges». Следующее было зарегистрировано в IANA.

5.4.1. Тип интернет-медиа multipart/byteranges

Введите имя: multipart

Название подтипа: byteranges

Обязательные параметры: boundary (граница)

Дополнительные параметры: N / A

Вопросы кодирования: разрешены только «7-битные», «8-битные» или «двоичные»

Вопросы безопасности: см. Раздел 6

Вопросы совместимости: нет данных

Опубликованная спецификация: эта спецификация (см. Приложение A).

Приложения, использующие этот тип мультимедиа: компоненты HTTP, поддерживающие несколько диапазонов в одном запросе.

Особенности идентификатора фрагмента: нет данных

Дополнительная информация:

Устаревшие псевдонимы для этого типа: N / A

Магическое число (а): N / A

Расширение файла (ов): N / A

Код (ы) типов файлов Macintosh: N / A

Контактное лицо и адрес электронной почты для получения дополнительной информации: см. Раздел «Адреса авторов».

Использование по назначению: COMMON

Ограничения на использование: N / A

Автор: см. Раздел «Адреса авторов».

Сменить контроллер: IESG

 

6. Вопросы безопасности

Этот раздел предназначен для информирования разработчиков, поставщиков информации и пользователей об известных проблемах безопасности, специфичных для механизмов запроса диапазона HTTP. Более общие соображения безопасности рассматриваются в сообщениях HTTP [RFC7230 #] и семантике [RFC7231 #].

6.1. Атаки типа «отказ в обслуживании» с использованием диапазона

Неограниченные запросы нескольких диапазонов подвержены атакам типа «отказ в обслуживании», потому что усилия, требуемые для запроса множества перекрывающихся диапазонов одних и тех же данных, незначительны по сравнению с временем, памятью и пропускной способностью, потребляемыми при попытке обслуживания запрошенных данных во многих частях. Серверы должны игнорировать, объединять или отклонять необоснованные запросы диапазонов, такие как запросы для более чем двух перекрывающихся диапазонов или для многих небольших диапазонов в одном наборе, особенно когда диапазоны запрашиваются не по порядку без видимой причины. Запросы из нескольких частей не предназначены для поддержки произвольного доступа.

7. Благодарности

См. Раздел 10 [RFC7230 #].

8. Ссылки

8.1. Нормативные ссылки

[RFC2046] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types», RFC 2046, November 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, June 2014.

[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content», RFC 7231, June 2014.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests», RFC 7232, June 2014.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, June 2014.

8.2. Информационные ссылки

[BCP13] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, January 2013.

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

Приложение А. Тип интернет-медиа multipart/byteranges

Когда ответное сообщение 206 (частичное содержимое) включает в себя содержимое нескольких диапазонов, они передаются как части тела в теле составного сообщения ([RFC2046 #], раздел 5.1) с типом мультимедиа «multipart/byteranges».

Мультимедийный тип «multipart/byteranges» включает одну или несколько частей тела, каждая из которых имеет свои собственные поля Content-Type и Content-Range. Обязательный параметр «border» указывает граничную строку, используемую для разделения каждой части тела.

Замечания по реализации:

1. Дополнительные CRLF могут предшествовать первой граничной строке в теле.
2. Хотя [RFC2046 #] разрешает заключать в кавычки граничную строку, некоторые существующие реализации неправильно обрабатывают указанную граничную строку.
3. Ряд клиентов и серверов были закодированы в ранней версии спецификации байтов, в которой использовался мультимедийный тип «multipart/x-byteranges», который почти (но не совсем) совместим с этим типом.

Несмотря на название, тип носителя «multipart/byteranges» не ограничен байтовыми диапазонами. В следующем примере используется единица измерения «exampleunit»:

HTTP/1.1 206 Partial Content
Date: Tue, 14 Nov 1995 06:25:24 GMT
Last-Modified: Tue, 14 July 04:58:08 GMT
Content-Length: 2331785
Content-Type: multipart/byteranges; boundary=THIS_STRING_SEPARATES

--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 1.2-4.3/25

...the first range...
--THIS_STRING_SEPARATES
Content-Type: video/example
Content-Range: exampleunit 11.2-14.3/25

...the second range
--THIS_STRING_SEPARATES--

Приложение B. Изменения по сравнению с RFC 2616

Серверы получают больше свободы в том, как они реагируют на запрос диапазона, чтобы уменьшить злоупотребления со стороны злонамеренных (или просто жадных) клиентов. (Раздел 3.1)

Слабый валидатор не может быть использован в ответе 206. (Раздел 4.1)

Поле заголовка Content-Range имеет смысл только тогда, когда код состояния явно определяет его использование. (Раздел 4.2)

Эта спецификация представляет реестр единиц измерения дальности. (Раздел 5.1)

«multipart/byteranges» может состоять из одной части. (Приложение A)

Приложение C. Импортированный ABNF

Следующие основные правила включены посредством ссылки, как определено в Приложении B.1 [RFC5234 #]: ALPHA (буквы), CR (возврат каретки), CRLF (CR LF), CTL (элементы управления), DIGIT (десятичное 0-9) , DQUOTE (двойная кавычка), HEXDIG (шестнадцатеричный 0-9 / A-F / a-f), LF (перевод строки), OCTET (любая 8-битная последовательность данных), SP (пробел) и VCHAR (любой видимый символ US-ASCII ).

Обратите внимание на то, что все правила, полученные из токена, должны сравниваться без учета регистра, например, range-unit и допустимые диапазоны.

Правила ниже определены в [RFC7230 #]:

OWS = <OWS, смотри [RFC7230 #], Раздел 3.2.3>
token = <token, смотри [RFC7230 #], Раздел 3.2.6>

Правила ниже определены в других частях:

HTTP-date = <HTTP-date, смотри [RFC7231 #], Раздел 7.1.1.1>
entity-tag = <entity-tag, смотри [RFC7232 #], Раздел 2.3>

Приложение D. Собранный ABNF

В приведенной ниже ABNF правила списка расширены в соответствии с разделом 1.2 [RFC7230 #].

Accept-Ranges = acceptable-ranges

Content-Range = byte-content-range / other-content-range

HTTP-date = <HTTP-date, смотри [RFC7231 #], Раздел 7.1.1.1>

If-Range = entity-tag / HTTP-date

OWS = <OWS, смотри [RFC7230 #], Раздел 3.2.3>

Range = byte-ranges-specifier / other-ranges-specifier

acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS range-unit ] ) ) / "none"

byte-content-range = bytes-unit SP ( byte-range-resp /
unsatisfied-range )
byte-range = first-byte-pos "-" last-byte-pos
byte-range-resp = byte-range "/" ( complete-length / "*" )
byte-range-set = *( "," OWS ) ( byte-range-spec /
suffix-byte-range-spec ) *( OWS "," [ OWS ( byte-range-spec /
suffix-byte-range-spec ) ] )
byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
byte-ranges-specifier = bytes-unit "=" byte-range-set
bytes-unit = "bytes"

complete-length = 1*DIGIT

entity-tag = <entity-tag, смотри [RFC7232 #], Раздел 2.3>

first-byte-pos = 1*DIGIT

last-byte-pos = 1*DIGIT

other-content-range = other-range-unit SP other-range-resp
other-range-resp = *CHAR
other-range-set = 1*VCHAR
other-range-unit = token
other-ranges-specifier = other-range-unit "=" other-range-set

range-unit = bytes-unit / other-range-unit

suffix-byte-range-spec = "-" suffix-length

suffix-length = 1*DIGIT

token = <token, смотри [RFC7230 #], Раздел 3.2.6>

unsatisfied-range = "*/" complete-length

Индекс

2

206 Partial Content (status code) 10

4

416 Range Not Satisfiable (status code) 15

A

Accept-Ranges header field 7

C

Content-Range header field 12

G

Grammar

Accept-Ranges 7
acceptable-ranges 7
byte-content-range 12
byte-range 12
byte-range-resp 12
byte-range-set 5
byte-range-spec 5
byte-ranges-specifier 5
bytes-unit 5
complete-length 12
Content-Range 12
first-byte-pos 5
If-Range 9
last-byte-pos 5
other-content-range 12
other-range-resp 12
other-range-unit 5, 7
Range 8
range-unit 5
ranges-specifier 5
suffix-byte-range-spec 6
suffix-length 6
unsatisfied-range 12

I

If-Range header field 9

M

Media Type
multipart/byteranges 18, 21
multipart/x-byteranges 19
multipart/byteranges Media Type 18, 21
multipart/x-byteranges Media Type 21

R

Range header field 8

Адреса авторов

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/

Yves Lafon (editor)
World Wide Web Consortium
W3C / ERCIM
2004, rte des Lucioles
Sophia-Antipolis, AM 06902
France
EMail: ylafon@w3.org

URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/