- 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