Ambiguity in the Range header

When a request contains a Range header, it specifies a (byte) range of
the representation body. However, the server doesn't know which
representation the client is talking about.

Here is an example of firefox failing to resume download a gzip-ed body:

request 1

  GET / HTTP/1.1
  Accept-Encoding: gzip, deflate

response 1

  HTTP/1.1 200 OK
  Accept-Ranges: bytes
  Content-Encoding: gzip
  ETag: "135e962713f.gz"
  Last-Modified: Tue, 06 Mar 2012 19:00:37 GMT
  Content-Length: 182,249,279

Firefox decompress the body on the fly, and saves the decompressed
content to disk.

Now pause the download, firefox has 68,712,649 bytes decompressed data on disk.

Now resume the download, firefox tries to request range [68,712,649-]
of uncompressed body

request 2
  GET / HTTP/1.1
  Accept-Encoding: gzip, deflate
  Range: bytes=68,712,649-
  If-Match: "135e962713f.gz"
  If-Unmodified-Since: Tue, 06 Mar 2012 19:00:37 GMT

response 2

  HTTP/1.1 206 Partial Content
  Accept-Ranges: bytes
  Content-Range: bytes 68,712,649-182,249,278/182,249,279
  Content-Encoding: gzip
  ETag: "135e962713f.gz"
  Last-Modified: Tue, 06 Mar 2012 19:00:37 GMT
  Content-Length: 113,536,630

Unfortunately the server has no idea that the range is for the
uncompressed body. It returns the range of the gzip-ed body, which
seems to be the best choice. Then firefox fails since it expects
uncompressed body.

Is the server at fault here? Is there an understanding that Range is
always for the "plain" body without any Content-Encoding?

Zhong Yu

Received on Thursday, 4 October 2012 05:05:01 UTC