when we continue a download, make sure the file isnt already
complete, as otherwise the server might respond with a 416
as the range request will out of range.
apache sends Content-Encoding: gzip header for Content-Type: application/x-gzip
causing hget to decompress tgz files.
from the w3c:
The Content-Encoding entity-header field is used as a modifier to the media-type.
When presented, its value indicates what additional content codings have been applied
to the entity-body, and thus what decoding mechanisms must be applied in order to
obtail the media-type referenced by the Conent-Type header field. Content-Encoding
is primarily used to allow a document to be compressed without losing the
identity of its underlying media type.
this is clearly silly, as the file is already compressed, and decompressing it
will not yield the indicated Content-type: application/x-gzip, but a tarball.
examples:
http://zlib.net/zlib-1.2.8.tar.gzhttps://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50f.tgz
problems that need to be addressed:
- reads in the whole /proc every second for no reason
- breaks when http server doesnt include Content-Length header
- length is wrong for continued download (-o option)
