To me, trying to continue a file where it last stopped should produce a
valid file in the end, no matter how many retries/continues it took. The
truth of the matter is that the actual file is broken (16 reties), that's
why I thought it had something to do with continuing. Unfortunately, I
haven't been able to download the file in only one try, for the moment.

The rollback/garbage bytes things is something I have read long ago in the
documentation of some download manager (maybe GetRight) : it was some
security feature in case the server had a bad behaviour when giving up.
Again, I can't check my partial files to see if it's the case, for I
haven't the whole file now.

Thanks for your answers though.

---
Cordialement,
Philippe HAMEAU
On Tue, 8 Jan 2008, Philippe HAMEAU wrote:
> Second issue : in the end, the file is broken. I guess it's a problem 
with 
> continuing.
That's just a blind guess on your behalf. What makes you say this?
> Maybe some garbage bytes are received when a connection is about to die.
That's not normal. What makes you think this happens?
> Is there a way to tell the "--continue " directive to rollback some, 
let's 
> say, 4K ?
Nope.
-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
" Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes  pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel  ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite." 
" This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited."