Mon 27 Oct 2008 07:39:14 PM UTC, comment #1:
Actually, the server indicated conflicting content lengths after the reconnect:
...
Content-Length: 6963752
Content-Range: 4299196-11262948/11262948
...
While the content-length header correctly indicates that it is going to send 6963752 bytes, the content-range actually indicates that it is going to send 6963753 bytes (because byte 4299196 must also be counted)). It is nonsensically claiming that it is going to send byte 11262948, which is the 11262949th byte out of 11262948 total bytes. Wget 1.11.x now uses the content-range to determine length when appropriate, as some servers have also been known to issue incorrect content-lengths, or sometimes doesn't specify it at all, when serving partial content).
So that's the server's issue, not Wget's, and you should contact rapidshare.com about that (I will try to contact them as well).
However, Wget's behavior when receiving a 200 response with a content-length that matches the local file's size is currently to download the full content, where it should probably just close the connection. This behavior is also present in 1.10, was reported recently to the mailing list, and appears to be a regression over 1.9.1 or thereabouts. It is being tracked at https://savannah.gnu.org/bugs/index.php?24662
|