At 07:12 AM 9/10/2005 , Daniel Stenberg wrote:
>Retry (currently) only retries for transient errors (basically that means
>for HTTP: response code >= 500) and timeouts, not for closed connections
>during a successful transfer.
>
>But --retry is a fairly new addition to curl, it most probably needs some
>tweaking still to become really good.

It seems to me that retry should try to re-open a closed connection and
continue the transfer.

>Only if we change the current meaning for --retry. Also, when you download
>a stream we don't know how big it'll be so how can curl tell if the
>closure is premature or not?

Thats why I am thinking that there should be an option to specify the
number of bytes to download. It could keep retrying/restarting until it
transfers the specified number of bytes or exceeds the specified number of
retry's.

>I still believe the range option is what you want and unless it works
>already, we could investigate why it doesn't.

When I use the --range option it stops transferring and does not resume.
But it does not exit either. It continues counting off the time but no data
is being transferred.

>What happens then? -C - is the way to do resumed transfers. And that's the
>way --retry does internally when it retries transfers.

I get the following:
----------------------------------------------
** Resuming transfer from byte position 192512
   % Total % Received % Xferd Average
Speed Time Time Time Current
                                  Dload Upload Total Spent Left Speed
   0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
----------------------------------------------

>Windows doesn't offer any proper scripting abilities at all by default, so
>I can only recommend that you download and install something before you
>try to script anything (like perl, python, tcl or whatever your personal
>preference is).

I had not thought about using Perl. That may work. But it seems like what I
am doing is simple enough that I shouldn't need to do scripting to get it
to work. Is there a reason why it only retries after transient errors and
not after closed connections? It seems that cURL would be more robust if it
could continue to retry/restart a transfer until the time or file size has
been exceeded.

>curl the command line tool will never be able to provide every imaginable
>option or combination of options. It does however provide enough options
>to allow users to do almost everything,

Its amazing how much cURL does do. I am hoping I can figure out the correct
combination of options to get it to work for me. This is the third tool
that I have tried using to do this and it is clearly the most comprehensive.

I know downloading streams is a specialized use for cURL. Probably not the
typical HTTP application. That is why I was thinking that a --Stream option
would be useful. It would make it easier to get it to do things that are
unique to downloading a stream. But maybe there is a combination of
existing options that will already work.
Received on 2005-09-10