- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Fri, 14 Nov 97 13:39:51 PST
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
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
value
(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.
-Jeff
Received on Friday, 14 November 1997 13:41:45 UTC