알 수없는 길이의 파일을 다시 시작하기위한 콘텐츠 범위

Question

이미 압축 된 기존 자료 (노드를 사용하여)에서 알 수없는 길이의 ZIP 자료를 직접 작성합니다 (). ZIP 아카이브에서는 파일이 저장됩니다. ZIP은 단일 컨테이너 만 사용됩니다. 그래서 생성 된 ZIP 파일을 캐싱하는 것은 의미가 없습니다. 실제 계산이 필요 없습니다.

지금까지는 확인되었습니다. 이제 다운로드 재개 허가를 받고 싶습니다. Accept-Range, Range 및 Content-Range HTTP 헤더를 읽었습니다. 깨진 다운로드가있는 클라이언트는 개방형 범위 (예 : Range: bytes=8000000-)를 요청합니다.

어떻게 대답합니까? 내 대답은 RFC 2616 § 14.16에 따라,이 콘텐츠-Range 헤더를 포함해야합니다 : 바이트 범위 지정자 값과는 달리

(섹션 14.35.1 참조)하는 바이트 - 범위 - RESP 스펙은 하나를 지정해야 범위의 첫 번째 및 마지막 바이트에 대한 절대 바이트 위치를 포함해야합니다.

그래서 "위치 X에서 시작하는 모든 것"을 보낼 수 없으며, 알려진 크기의 일부만 전송하거나 길이를 미리 계산하여 마지막 바이트도 지정해야합니다. 두 가지 아이디어 모두 내 상황에 편리하지 않습니다. 다른 가능성이 있습니까?

Answer 1

자신을 답하는 중 : 나는 (1) 아직 알 수없는 길이의 파일을 청크로 인코딩하거나 (2) Content-Length (또는 현재 부분의 크기)를 알고 있어야하며, 다운로드를 다시 시작하기위한 것 (진행 막대뿐만 아니라).

내 ZIP 파일 각각에 대해 길이가 동일하므로 어딘가에 저장할 수 있고 후속 다운로드에 다시 사용할 수 있습니다. 나는 HTTP 프로토콜이 알 수없는 길이의 다운로드를 재개하지 못하게하는 것에 놀랐다.

Answer 2

"multipart/byteranges"Content-Type (각 부품의 Content-Range 필드 포함)에 대한 응답.

추론 :

1. 206 HTTP 상태 코드 응답 중 "내용 - 범위"헤더를 제시 (14.35.1 Byte Ranges section)

2. (206)를보고해야한다 "범위"헤더, 성공적인 부분 응답과 요청에 회신 또는 "multipart/byteranges"Content-Type (10.2.7 206 Partial Content)

3. "Content-Range"헤더는 끝 위치를 생략 할 수 없으므로 응답에 추가 할 수 없으므로 단지 왼쪽 방법은 "다중/byteranges를"Content-Type을