Content-Range for resuming a file of unknown length

Question

I create a ZIP archive on-the-fly of unknown length from existing material (using Node), which is already compressed. In the ZIP archive, files just get stored; the ZIP is only used to have a single container. That's why caching the created ZIP files makes no sense -there's no real computation involved.

So far, OK. Now I want to permit resuming downloads, and I'm reading about Accept-Range, Range and Content-Range HTTP headers. A client with a broken download would ask for an open-ended range, say: Range: bytes=8000000-.

How do I answer that? My answer must include a Content-Range header, and there, according to RFC 2616 § 14.16 :

Unlike byte-ranges-specifier values (see section 14.35.1), a byte- range-resp-spec MUST only specify one range, and MUST contain absolute byte positions for both the first and last byte of the range.

So I cannot just send "everything starting from position X", I must specify the last byte sent, too - either by sending only a part of known size, or by calculating the length in advance. Both ideas are not convenient to my situation. Is there any other possibility?

Emmi

Answer 1

Answering myself: Looks like I have to choose between (1) chunked-encoding of a file of yet unknown length, or (2) knowing its Content-Length (or at least the size of the current part), allowing for resuming downloads (as well as for progress bars).

I can live with that - for each of my ZIP files, the length will be the same, so I can store it somewhere and re-use it for subsequent downloads. I'm just surprised the HTTP protocol does not allow for resuming downloads of unknown length.

Emmi

Answer 2

Response with "multipart/byteranges" Content-Type including Content-Range fields for each part.

Reasoning:

1. When replying to requests with "Range" header, successful partial responses should report 206 HTTP status code (14.35.1 Byte Ranges section)

2. 206 response suggests either "Content-Range" header or "multipart/byteranges" Content-Type (10.2.7 206 Partial Content)

3. "Content-Range" header cannot be added to the response as it does not allow omitting end position, so the only left way is to use "multipart/byteranges" Content-Type

Adolescent

You really ought to look at the current spec (RFC 7233), not RFC 2616. – Troublemaker

How does that help? The Content-Range header within each multipart still requires knowledge about its end byte. – Jointed

unfortunately, it seems RFC7233 requires that "A server MUST NOT generate a multipart response to a request for a single range, since a client that does not request multiple parts might not support multipart responses". – Deron