HTTP 범위 헤더

HTTP 범위 헤더

---

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35 를 읽고 파일 다운로드를 계속하는 방법을 알아 내려고했습니다.

예를 들어 파일 길이가 100 바이트이고 모두 100 바이트라고 가정합니다. 그러나 예상되는 파일 크기가 무엇인지 모르기 때문에 파일을 요청하고 다음과 같은 Range 헤더를 지정합니다.

Range: bytes=100-

유효한 범위 요청입니까?

---

구문 적으로 유효한 요청이지만 만족스러운 요청은 아닙니다. 해당 섹션에서 더 자세히 살펴보면 다음을 참조하십시오.

구문 상 유효한 바이트 범위 세트가 첫 번째 바이트 위치가 엔티티 본문의 현재 길이보다 작은 하나 이상의 바이트 범위 스펙 또는 비가있는 접미사 바이트 범위 스펙을 포함하는 경우 -접미사 길이가 0이면 바이트 범위 집합이 만족 스럽습니다. 그렇지 않으면 바이트 범위 세트가 만족스럽지 않습니다. 바이트 범위 집합이 만족스럽지 않으면 서버는 상태가 416 (요청 된 범위가 만족스럽지 않음)의 응답을 반환해야합니다 (SHOULD) . 그렇지 않으면 서버는 엔티티 본문의 만족할 수있는 범위를 포함하는 206 (부분 콘텐츠) 상태의 응답을 반환해야합니다 (SHOULD).

따라서 귀하의 예에서 서버는 해당 파일에 대해 유효한 바이트 범위가 아니기 때문에 416을 반환해야한다고 생각합니다.

---

Wrikken이 제안 했듯이 유효한 요청입니다. 클라이언트가 미디어를 요청하거나 다운로드를 재개 할 때도 매우 일반적입니다.

클라이언트는 종종 서버가 Accept-Ranges응답을 찾는 것 외에 범위가 지정된 요청을 처리하는지 확인하기 위해 테스트합니다 . Chrome은 항상Range: bytes=0- 동영상에 대한 첫 번째 GET 요청과 함께를 전송 하므로 무시할 수 없습니다.

클라이언트 Range:가 요청에 포함 할 때마다 형식이 잘못 되었더라도 부분적인 콘텐츠 (206) 응답을 기대합니다. HTML5 비디오 재생 중에 앞으로 검색 할 때 브라우저는 시작 지점 만 요청합니다. 예를 들면 :

Range: bytes=3744-

따라서 클라이언트가 비디오를 제대로 재생하려면 서버가 이러한 불완전한 범위 요청을 처리 할 수 ​​있어야합니다.

질문에서 지정한 '범위'유형을 두 가지 방법으로 처리 할 수 ​​있습니다.

먼저 응답에 제공된 요청 된 시작 지점으로 응답 한 다음 파일의 총 길이에서 1을 뺀 값으로 응답 할 수 있습니다 (요청 된 바이트 범위는 제로 인덱싱 됨). 예를 들면 :

의뢰:

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/*

팁 :

항상 범위에 포함 된 콘텐츠 길이로 응답해야합니다. 범위가 시작부터 끝까지 완료되면 콘텐츠 길이는 단순히 차이입니다.

요청 : 범위 : bytes = 500-1000

응답 : Content-Range : 바이트 500-1000 / 123456

범위는 0 인덱스이므로 Range: bytes=0-999실제로 999가 아닌 1000 바이트를 요청하므로 다음과 같이 응답하십시오.

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

또는:

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

그러나 일부 미디어 플레이어는 파일 크기에서 기간을 알아 내려고하기 때문에 가능하면 후자의 방법을 사용하지 마십시오. 내 직감 인 미디어 콘텐츠에 대한 요청 인 경우 응답에 해당 기간을 포함해야합니다. 이는 다음 형식으로 수행됩니다.

X-Content-Duration: 63.23 

이것은 부동 소수점이어야합니다. 과 달리이 Content-Length값은 정확할 필요가 없습니다. 플레이어가 동영상을 탐색하는 데 사용됩니다. 웹 캐스트를 스트리밍하고 있고 얼마나 오래 걸릴지에 대한 일반적인 생각 만 가지고 있다면, 전체를 무시하는 것보다 예상 시간을 포함하는 것이 좋습니다. 따라서 2 시간짜리 웹 캐스트의 경우 다음과 같은 내용을 포함 할 수 있습니다.

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-

Some servers will send a regular 200 response as a reply, which it accepts (but with limited playback options), but try to send a 206 instead to show than your server handles ranges. RFC 2616 says it's acceptable to ignore range headers.

---

Contrary to Mark Novakowski answer, which for some reason has been upvoted by many, yes, it is a valid and satisfiable request.

In fact the standard, as Wrikken pointed out, makes just such an example. In practice, Firefox responds to such requests as expected (with a 206 code), and this is exactly what I use to implement progressive download, that is, only get the tail of a long log file which grows in real time with polling.

---

For folks who are stumbling across Victor Stoddard's answer above in 2019, and become hopeful and doe eyed, note that:

a) Support for X-Content-Duration was removed in Firefox 41: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/41#HTTP

b) I think it was only supported in Firefox for .ogg audio and .ogv video, not for any other types.

c) I can't see that it was ever supported at all in Chrome, but that may just be a lack of research on my part. But its presence or absence seems to have no effect one way or another for webm or ogv videos as of today in Chrome 71.

d) I can't find anywhere where 'Content-Duration' replaced 'X-Content-Duration' for anything, I don't think 'X-Content-Duration' lived long enough for there to be a successor header name.

I think this means that, as of today if you want to serve webm or ogv containers that contain streams that don't know their duration (e.g. the output of an ffpeg pipe) to Chrome or FF, and you want them to be scrubbable in an HTML 5 video element, you are probably out of luck. Firefox 64.0 makes a half hearted attempt to make these scrubbable whether or not you serve via range requests, but it gets confused and throws up a spinning wheel until the stream is completely downloaded if you seek a few times more than it thinks is appropriate. Chrome doesn't even try, it just nopes out and won't let you scrub at all until the entire stream is finished playing.

참고URL : https://stackoverflow.com/questions/3303029/http-range-header