Czytałem http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 i próbowałem dowiedzieć się, jak kontynuować pobieranie pliku.
Na przykład załóżmy, że plik ma długość 100 bajtów, a ja mam wszystkie 100 bajtów. Jednak nie wiem, jaki powinien być oczekiwany rozmiar pliku, więc pytam o plik i określam nagłówek Range, który wygląda następująco:
Range: bytes=100-
Czy to prawidłowe żądanie dotyczące zakresu?
Odpowiedzi:
Jest to żądanie poprawne składniowo, ale nie spełniające wymagań. Jeśli spojrzysz dalej w tej sekcji, zobaczysz:
Jeśli składniowo poprawny zestaw zakresu bajtów zawiera co najmniej jedną specyfikację zakresu bajtów, której pozycja pierwszego bajtu jest mniejsza niż bieżąca długość ciała jednostki, lub co najmniej jedną specyfikację zakresu bajtów sufiksu z wartością inną niż - zerowa długość sufiksu, wtedy zestaw zakresu bajtów jest zadowalający. W przeciwnym razie zestaw zakresu bajtów jest niezadowalający. Jeśli zestaw zakresu bajtów jest niezadowalający, serwer POWINIEN zwrócić odpowiedź o statusie 416 (Żądany zakres nie jest spełniony) . W przeciwnym razie serwer POWINIEN zwrócić odpowiedź o statusie 206 (zawartość częściowa), zawierającą dopuszczalne zakresy treści jednostki.
Więc myślę, że w twoim przykładzie serwer powinien zwrócić 416, ponieważ nie jest to prawidłowy zakres bajtów dla tego pliku.
Jak zasugerował Wrikken , jest to poprawne żądanie. Jest to również dość powszechne, gdy klient żąda nośnika lub wznawia pobieranie.
Klient często sprawdza, czy serwer obsługuje żądania z zakresu innych niż tylko szukanie Accept-Rangesodpowiedzi. Chrome zawsze wysyła Range: bytes=0-z pierwszym żądaniem GET filmu, więc nie można tego odrzucić.
Za każdym razem, gdy klient dołącza Range:do swojego żądania, nawet jeśli jest źle sformułowany, oczekuje odpowiedzi częściowej zawartości (206). Kiedy szukasz do przodu podczas odtwarzania wideo HTML5, przeglądarka żąda tylko punktu początkowego. Na przykład:
Range: bytes=3744-
Tak więc, aby klient mógł prawidłowo odtwarzać wideo, Twój serwer musi być w stanie obsłużyć te niekompletne żądania zakresu.
Typ „zakresu” określony w pytaniu możesz obsłużyć na dwa sposoby:
Najpierw możesz odpowiedzieć z żądanym punktem początkowym podanym w odpowiedzi, a następnie całkowitą długością pliku minus jeden (żądany zakres bajtów jest indeksowany przez zero). Na przykład:
Żądanie:
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ć, podając punkt początkowy podany w żądaniu i otwartą długość (rozmiar) pliku. Dotyczy to transmisji internetowych lub innych mediów, w przypadku których całkowita długość nie jest znana. Na przykład:
Żądanie:
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:
Musisz zawsze odpowiadać, podając długość treści zawartą w zakresie. Jeśli zakres jest kompletny, od początku do końca, długość treści jest po prostu różnicą:
Żądanie: zakres: bajty = 500-1000
Odpowiedź: Zakres zawartości: bajty 500-1000 / 123456
Pamiętaj, że zakres jest indeksowany przez zero, więc w Range: bytes=0-999rzeczywistości żąda 1000 bajtów, a nie 999, więc odpowiedz na przykład:
Content-Length: 1000
Content-Range: bytes 0-999/123456
Lub:
Content-Length: 1000
Content-Range: bytes 0-999/*
Ale jeśli to możliwe, unikaj tej drugiej metody, ponieważ niektóre odtwarzacze multimedialne próbują obliczyć czas trwania na podstawie rozmiaru pliku. Jeśli Twoje żądanie dotyczy treści multimedialnych, co jest moim przeczuciem, w odpowiedzi podaj czas jego trwania. Odbywa się to w następującym formacie:
X-Content-Duration: 63.23
To musi być zmiennoprzecinkowa. W przeciwieństwie do Content-Lengthtego ta wartość nie musi być dokładna. Służy do pomocy graczowi w wyszukiwaniu filmów. Jeśli transmitujesz transmisję internetową i masz tylko ogólne pojęcie o tym, jak długo to potrwa, lepiej jest uwzględnić szacowany czas trwania, a nie całkowicie go zignorować. Tak więc w przypadku dwugodzinnej transmisji internetowej możesz dołączyć coś takiego:
X-Content-Duration: 7200.00
W przypadku niektórych typów multimediów, takich jak webm, musisz również uwzględnić typ zawartości, na przykład:
Content-Type: video/webm
Wszystko to jest niezbędne do prawidłowego odtwarzania multimediów, zwłaszcza w HTML5. Jeśli nie podasz czasu trwania, gracz może spróbować obliczyć czas trwania (aby umożliwić wyszukiwanie) na podstawie rozmiaru pliku, ale nie będzie to dokładne. Jest to w porządku i konieczne do transmisji internetowych lub transmisji na żywo, ale nie jest idealne 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 w nazwie pliku.
X-Content-Durationjest wycofywany na korzyść Content-Duration, więc to też bym uwzględnił. Podstawowa odpowiedź na żądanie „0-” zawierałaby co najmniej następujące elementy:
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 kwestia: Chrome zawsze rozpoczyna pierwsze żądanie wideo od następujących:
Range: bytes=0-
Niektóre serwery wyślą zwykłą odpowiedź 200 jako odpowiedź, którą zaakceptuje (ale z ograniczonymi opcjami odtwarzania), ale zamiast tego spróbuj wysłać 206, aby pokazać, że twój serwer obsługuje zakresy. RFC 2616 mówi, że ignorowanie nagłówków zakresów jest dopuszczalne.
W przeciwieństwie do odpowiedzi Marka Novakowskiego, która z jakiegoś powodu spotkała się z poparciem wielu, tak, jest to uzasadniona i satysfakcjonująca prośba.
W rzeczywistości standard, jak wskazał Wrikken, jest właśnie takim przykładem. W praktyce Firefox odpowiada na takie żądania zgodnie z oczekiwaniami (kodem 206) i właśnie tego używam do implementacji pobierania progresywnego, to znaczy otrzymuję tylko koniec długiego pliku dziennika, który rośnie w czasie rzeczywistym wraz z odpytywaniem.
Dla osób, które natkną się na powyższą odpowiedź Victora Stoddarda w 2019 r. I nabierają nadziei i łzawych oczu, zauważ, że:
a) Wsparcie dla X-Content-Duration zostało usunięte w Firefoksie 41: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/41#HTTP
b) Myślę, że był obsługiwany tylko w Firefoksie dla audio i wideo .ogg, a nie dla innych typów.
c) Nie widzę, żeby kiedykolwiek było obsługiwane w Chrome, ale może to być po prostu brak badań z mojej strony. Jednak jego obecność lub brak wydaje się nie mieć żadnego wpływu w taki czy inny sposób na filmy webm lub ogv od dzisiaj w Chrome 71.
d) Nie mogę znaleźć miejsca, w którym „Content-Duration” zastąpiło „X-Content-Duration”, nie sądzę, że „X-Content-Duration” istniało wystarczająco długo, aby następna nazwa nagłówka była.
Myślę, że oznacza to, że od dzisiaj, jeśli chcesz udostępniać kontenery webm lub ogv, które zawierają strumienie, które nie znają czasu ich trwania (np. Wyjście potoku ffpeg), do Chrome lub FF i chcesz, aby można je było czyścić w element wideo HTML 5, prawdopodobnie nie masz szczęścia. Firefox 64.0 podejmuje połowiczną próbę uczynienia tych rzeczy łatwymi do szorowania, niezależnie od tego, czy obsługujesz żądania dotyczące zakresu, ale jest zdezorientowany i rzuca kołowrotkiem, dopóki strumień nie zostanie całkowicie pobrany, jeśli szukasz kilka razy więcej, niż uważa za stosowne. Chrome nawet nie próbuje, to po prostu nopes się i nie pozwoli Ci szorować wcale aż cały strumień jest gotowy do gry .