Ответ HTTP/1.1 на несколько диапазонов

Во время написания моего сервера HTTP/1.1 я застрял, обрабатывая запрос с несколькими диапазонами.

Раздел 14.35.1 RFC 2616 ссылается на некоторые примеры, но не разъясняет поведение сервера. Например:

GET /some/resource HTTP/1.1
...
Range: bytes=200-400,100-300,500-600
...

Должен ли я вернуть эту точную последовательность байтов? Или мне объединить все диапазоны, отправив 100-400,500-600? Или отправить все между ними, 100-600?

Хуже всего то, что при проверке заголовка ответа Content-Range (раздел 14.16) может быть возвращен только один диапазон, поэтому мне интересно, как ответит сервер на пример из раздела 14.35.1 bytes=0-0,-1!!!

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


person LS_ᴅᴇᴠ    schedule 19.08.2013    source источник


Ответы (1)


Я просто посмотрел, как могут реагировать другие серверы, поддерживающие поле заголовка Range, и сделал быстрый curl на example.com:

~# curl -s -D - -H "Range: bytes=100-200, 300-400" http://www.example.com
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385
Server: ECS (fll/0761)


--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="vieport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--

Судя по всему, вы ищете заголовок ответа Content-Type: multipart/byteranges; boundary. Погуглив именно это, я обнаружил документ W3C с приложениями к RFC 2616.

Когда ответное сообщение HTTP 206 (частичное содержимое) включает содержимое нескольких диапазонов (ответ на запрос несколько непересекающихся диапазонов), они передаются как составное тело сообщения. Тип носителя для этой цели называется "multipart/byteranges".
Тип носителя multipart/byteranges включает две или более частей, каждая из которых имеет свои собственные поля Content-Type и Content-Range. Обязательный граничный параметр задает граничную строку, используемую для разделения каждой части тела.

Так вот.

Кстати, сервер по адресу example.com не проверяет перекрывающиеся диапазоны байтов и отправляет вам именно те диапазоны, которые вы просил...

person PoByBolek    schedule 21.08.2013
comment
Вы попали в точку! Признаюсь, я не пробовал, потому что боялся, что это может привести к какому-то специфичному для сервера поведению, а не какому-то стандартному. Спасибо! - person LS_ᴅᴇᴠ; 21.08.2013
comment
Кстати, можно ли отправлять несколько ответов с индивидуальным диапазоном? Также по запросу @LS_ᴅᴇᴠ Можно ли отправлять все диапазоны вместе? т.е. 100-200, 300-400, 500-600 ==> 100-600? - person iammilind; 08.02.2020
comment
@iammilind посмотрите RFC 7233, в котором определяется код состояния ответа 206 Partial Content. : Когда запрашивается несколько диапазонов, сервер МОЖЕТ объединить любой из перекрывающихся диапазонов... Но вы можете отправить только один ответ на запрос. - person PoByBolek; 10.02.2020
comment
Спасибо. Но что, если сервер может поддерживать не несколько диапазонов, а только один диапазон? Кроме того, если диапазоны не перекрываются, может ли сервер отправить любой комбинированный диапазон, который клиент не запрашивал? Я спрашиваю с точки зрения реализации сервера. - person iammilind; 10.02.2020
comment
@iammilind Все еще цитирует RFC 7233 и то же предложение, что и раньше: Когда несколько запрашиваются диапазоны, сервер МОЖЕТ объединить любой из диапазонов, которые перекрываются или которые разделены промежутком, который меньше, чем накладные расходы на отправку нескольких частей, независимо от порядка, в котором соответствующая спецификация диапазона байтов появилась в полученном Поле заголовка диапазона. Если вы спрашиваете с точки зрения реализации, вам действительно следует прочитать этот RFC;) - person PoByBolek; 10.02.2020