9

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?

Dror Bereznitsky
  • 20,048
  • 3
  • 48
  • 57
cato_minor
  • 663
  • 6
  • 11

2 Answers2

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.

cato_minor
  • 663
  • 6
  • 11
0

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

Yaegor
  • 1,771
  • 9
  • 12
  • You really ought to look at the current spec (RFC 7233), not RFC 2616. – Julian Reschke Jul 09 '14 at 18:51
  • How does that help? The `Content-Range` header within each multipart still requires knowledge about its end byte. – Hank Dec 09 '16 at 14:07
  • 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". – Julian Dec 03 '20 at 11:46