Re: Ambiguity in the Range header

I raised a similar query quite a while back and the general view was that
since it is Transfer-encoded and not content-encoded, the range refers to
the original content/plain text. But I wasn't able to find any specific
section in the drafts/RFC.

But then I realize that makes a cache's (both middleware/client side) life
difficult. if it is missing a piece of puzzle, it can't simply request that
piece missing in the middle and plug the hole. it needs to get the entire
content from the missing part till end and inflate both pieces and then
assemble them. Hope someone more knowledgeable on this matter has solved
this.

On Thu, Oct 4, 2012 at 10:34 AM, Zhong Yu <zhong.j.yu@gmail.com> wrote:

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


-- 
.- ... .... --- -.-