W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1997

Re: new editorial issue RANGE_WITH_CONTENTCODING

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 14 Nov 97 13:39:51 PST
Message-Id: <9711142139.AA19964@acetes.pa.dec.com>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4666
Dave Morris writes

    one of the 'justifications' for byte ranges was the ability to
    continue retrieving a previously interrupted response. In that
    mode, if I were the developer of the client, I would want the byte
    range to apply to the compressed form.

If one starts with three assumptions (which might even be "facts"):

    (1) The interruption affects the tail of a retrieval.
    (2) Most HTTP retrievals are attempting to transfer the whole resource
    (3) The compression algorithms that we actually use are one-pass
    algorithms with finite windows, and so it is possible to extract
    a large portion of the uncompressed form from a partial copy
    of the compressed form.

Then even in the case where one is recovering from an interrupted
retrieval of a compressed form, you will be in a situation where
you have been able to decompress some prefix of the full file.

This means that the ability to ask the server for a compressed
copy of the part of the file that you don't have is sufficient to
recover from the loss.  Further, because of the relatively small
window used by compression algorithms, the result would not be
much larger than if you were able to retransmit exactly the bytes
of the compressed form that were previously unavailable.

Further, a slice out of the middle of a compressed form is totally
useless by itself; e.g., you can't decompress the output of gzip
without knowing the first few bytes of the output, because the
rest of the compression depends on that prefix.  On the other hand,
a compressed form of a slice of the uncompressed form has some
value, since it is possible to extract the unencoded slice.

Received on Friday, 14 November 1997 13:41:45 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:21 UTC