HTTP-заголовок Range

как Wrikken предложил, это действительный запрос. Это также довольно часто, когда клиент запрашивает носитель или возобновляет загрузку.

клиент часто проверяет, обрабатывает ли сервер ранжированные запросы, кроме как просто ищет Accept-Ranges ответ. Хром всегда передает Range: bytes=0- С его первым получить запрос на видео, так что это то, что вы не можете уволить.

всякий раз, когда клиент включает в себя Range: в своем запросе, даже если он деформирован, он ожидает частичного ответа на контент (206). При поиске вперед во время воспроизведения видео HTML5 браузер запрашивает только начальную точку. Например:

Range: bytes=3744-

таким образом, чтобы клиент мог правильно воспроизводить видео, ваш сервер должен иметь возможность обрабатывать эти неполные запросы диапазона.

вы можете обрабатывать тип "диапазона", указанный в вашем вопросе, двумя способами:

во-первых, вы смогли ответить с спрошенным начальная точка задается в ответе, затем общая длина файла минус один (запрошенный диапазон байтов индексируется нулем). Например:

запрос:

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100-

ответ:

206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/64656927

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

запрос:

GET /BigBuckBunny_320x180.mp4
Range: bytes=100-

ответ:

206 Partial Content
Content-Type: video/mp4
Content-Length: 64656927
Accept-Ranges: bytes
Content-Range: bytes 100-64656926/*

советы:

вы всегда должны отвечать длиной содержимого, включенной в диапазон. Если диапазон завершен, с начала до конца, то длина содержимого-это просто разница:

запрос: Диапазон: число байт=500-1000

ответ: Контент-диапазон: 500-1000 байт/123456

помните, что диапазон имеет нулевую индексацию, поэтому Range: bytes=0-999 на самом деле запрашивает 1000 байт, а не 999, поэтому ответьте чем-то вроде:

Content-Length: 1000
Content-Range: bytes 0-999/123456

или:

Content-Length: 1000
Content-Range: bytes 0-999/*

но, избегайте последнего метода, если это возможно, потому что некоторые медиа-плееры пытаются выяснить продолжительность от размера файла. Если ваш запрос касается медиа-контента, что является моей догадкой, то вы должны включить его продолжительность в ответ. Это делается в следующем формате:

X-Content-Duration: 63.23 

это должно быть с плавающей точкой. В отличие от Content-Length, это значение не обязательно должно быть точным. Он используется, чтобы помочь игроку искать вокруг видео. Если вы потокового вещания и иметь только общее представление о том, как долго это будет, лучше указать свой предполагаемый срок, а не игнорировать его. Итак, для двухчасовой веб-трансляции вы можете включить что-то вроде:

X-Content-Duration: 7200.00 

для некоторых типов носителей, таких как webm, необходимо также включить тип содержимого, например:

Content-Type: video/webm 

все это необходимо для медиа, чтобы играть правильно, особенно в HTML5. Если вы не даете продолжительность, игрок может попытаться выяснить продолжительность (чтобы разрешить поиск) из своего размера файла, но это не будет точным. Это нормально, и необходимо для трансляции или в прямом эфире, но не подходит для воспроизведения видео файлов. Вы можете извлечь продолжительность с помощью программного обеспечения, как FFMPEG и сохранить его в базе данных или даже имя файла.

X-Content-Duration постепенно сворачивается в пользу Content-Duration, так что я бы включил это тоже. Один основной, ответ на запрос " 0-" будет включать, по крайней мере, следующее:

HTTP/1.1 206 Partial Content
Date: Sun, 08 May 2013 06:37:54 GMT
Server: Apache/2.0.52 (Red Hat)
Accept-Ranges: bytes
Content-Length: 3980
Content-Range: bytes 0-3979/3980
Content-Type: video/webm
X-Content-Duration: 2054.53
Content-Duration: 2054.53

еще один момент: Chrome всегда начинает свой первый запрос видео со следующего:

Range: bytes=0-

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

В отличие от ответа Марка Новаковского, который по какой-то причине был поддержан многими, да, это действительный и выполнимый запрос.

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