Nagłówek zakresu HTTP

Jak zasugerował Wrikken, jest to poprawna Prośba. Jest to również dość powszechne, gdy klient żąda mediów lub wznawia pobieranie.

Klient często testuje, aby sprawdzić, czy serwer obsługuje żądania dystansowe inne niż szukanie odpowiedzi Accept-Ranges. Chrome zawsze wysyła Range: bytes=0- z pierwszą prośbą o pobranie wideo, więc jest to coś, czego nie można odrzucić.

Ilekroć klient zawiera Range: w swoim żądaniu, nawet jeśli jest zniekształcony, oczekuje odpowiedź częściowa (206) Gdy szukasz do przodu podczas odtwarzania wideo HTML5, przeglądarka żąda tylko punktu początkowego. Na przykład:

Range: bytes=3744-

Więc, aby klient mógł poprawnie odtwarzać wideo, twój serwer musi być w stanie obsłużyć te niekompletne żądania zasięgu.

Możesz obsługiwać typ 'zakresu', który podałeś w swoim pytaniu na dwa sposoby:

Najpierw możesz odpowiedzieć żądanym punktem wyjścia podanym w odpowiedzi, a następnie całkowitą długością plik minus jeden (żądany zakres bajtów jest indeksowany zerowo). Na przykład:

Zapytanie:

GET /BigBuckBunny_320x180.mp4 
Range: bytes=100-

Odpowiedź:

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

Po drugie, możesz odpowiedzieć punktem wyjścia podanym w zapytaniu i otwartą długością pliku (rozmiarem). Dotyczy to webcastów lub innych mediów, w których całkowita długość nie jest znana. Na przykład:

Zapytanie:

GET /BigBuckBunny_320x180.mp4
Range: bytes=100-

Odpowiedź:

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

Porady:

Zawsze musisz odpowiadać z zawartą długością treści z Zasięgiem. Jeśli zakres jest kompletny, Od początku do końca, to długość zawartości jest po prostu różnicą:

Prośba: Range: bytes=500-1000

Odpowiedź: Content-Range: bytes 500-1000 / 123456

Pamiętaj, że zakres jest indeksowany zero, więc Range: bytes=0-999 W rzeczywistości żąda 1000 bajtów, a nie 999, więc odpowiadaj czymś w stylu:

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

Lub:

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

Ale unikaj tej drugiej metody, jeśli to możliwe, ponieważ niektóre odtwarzacze multimedialne próbują dowiedzieć się czas trwania od rozmiaru pliku. Jeśli twoja prośba dotyczy treści medialnych, co jest moim przeczuciem, powinieneś podać jej czas trwania w odpowiedzi. Odbywa się to w następującym formacie:

X-Content-Duration: 63.23 

To musi być zmiennoprzecinkowy. W przeciwieństwie do Content-Length, ta wartość nie musi być dokładna. Służy do pomocy graczowi w poszukiwaniu filmu. Jeśli streamujesz transmisję internetową i masz tylko ogólne pojęcie, jak długo będzie to trwało, lepiej uwzględnić szacowany czas trwania, niż go zignorować / align = "left" / Tak więc, dla dwugodzinnego webcastu, możesz dołączyć coś w stylu:

X-Content-Duration: 7200.00 

Content-Type: video/webm 

Wszystkie te elementy są niezbędne do prawidłowego odtwarzania multimediów, szczególnie w HTML5. Jeśli nie podasz czasu trwania, gracz może spróbować ustalić czas trwania (aby umożliwić wyszukiwanie) na podstawie rozmiaru pliku, ale nie będzie to dokładne. Jest to w porządku i konieczne dla webcast lub streamingu na żywo, ale nie idealny do odtwarzania plików wideo. Możesz wyodrębnić czas trwania za pomocą oprogramowania takiego jak FFMPEG i zapisać go w bazie danych lub nawet nazwę pliku.

X-Content-Duration jest wycofywany na rzecz Content-Duration, więc też bym to uwzględnił. Podstawowe, odpowiedź na żądanie" 0 - " będzie zawierać co najmniej następujące:

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

Jeszcze jedna uwaga: Chrome zawsze uruchamia swoje pierwsze żądanie wideo następującym tekstem:

Range: bytes=0-

Niektóre serwery wysyłają regularne 200 odpowiedzi jako odpowiedź, którą akceptuje (ale z ograniczonymi opcjami odtwarzania), ale spróbuj wysłać 206 zamiast pokazywać zakresy obsługi serwera. RFC 2616 mówi, że dopuszczalne jest ignorowanie nagłówków zakresu.

W przeciwieństwie do odpowiedzi Marka Nowakowskiego, która z jakiegoś powodu została upvotted przez wielu, tak, jest to słuszna i satysfakcjonująca Prośba.

W rzeczywistości norma, jak zauważył Wrikken, stanowi właśnie taki przykład. W praktyce Firefox reaguje na takie żądania zgodnie z oczekiwaniami (kodem 206) i właśnie tego używam do implementacji progresywnego pobierania, czyli tylko ogona długiego pliku dziennika, który rośnie w czasie rzeczywistym wraz z sondowaniem.