Linux curl m. retry funktion/syntax

Off topic - alt som ikke handler om musik eller studie.
Forumregler
Tænk dig om, tal pænt, men lad også være med at være meget sart. Hvis du skal bruge skældsord, så hold dig til noget Kaptajn Haddock ville have sagt.
Nyt svar
Medlemsavatar
Holger
Audio Alchemist
Indlæg: 37634
Sted: Fyn

Linux curl m. retry funktion/syntax

Indlæg af Holger »

Muligvis ikke det rigtige sted at spørge, men nørdfaktoren er høj herinde:

Jeg prøver at få curl til at retrie at downloade et link og outputte det i en fil (Bash & Ubuntu):

Kode: Vælg alt

$ curl -o filnavn --retry-all-errors 100 https://url.com/fil.zip
Jeg gætter på, at er syntaxen korrekt, da man vel er nødt til at have -o flaget efterfulgt direkte af filnavn og --retry-all-errors flaget efterfulgt at den numeriske værdi, fx 100 og herefter URL.

Ser det korrekt ud eller er der noget jeg misser, hvis formålet er at få systemet til med eksponentiel stigende tid (op til 10 minutter, så vidt jeg har forstået curl) mellem hvert forsøg at prøve at download URL'en indtil der er bid uanset typen af rapporteret fejl fra serveren (inkl. 404).

Medlemsavatar
Hald
Forum Donator
Indlæg: 10824
Sted: Vind / Holstebro

Indlæg af Hald »

Jeg er lidt i tvivl med det efterfulgte tal når du bruger den retry funktion.
Added in 7.21.3.

--retry-all-errors
Retry on any error. This option is used together with
--retry.

This option is the "sledgehammer" of retrying. Do not use
this option by default (eg in curlrc), there may be
unintended consequences such as sending or receiving
duplicate data. Do not use with redirected input or
output. You'd be much better off handling your unique
problems in shell script. Please read the example below.

Warning: For server compatibility curl attempts to retry
failed flaky transfers as close as possible to how they
were started, but this is not possible with redirected
input or output. For example, before retrying it removes
output data from a failed partial transfer that was
written to an output file. However this is not true of
data redirected to a | pipe or > file, which are not
reset. We strongly suggest don't parse or record output
via redirect in combination with this option, since you
may receive duplicate data.

By default curl will not error on an HTTP response code
that indicates an HTTP error, if the transfer was
successful. For example, if a server replies 404 Not Found
and the reply is fully received then that is not an error.
When --retry is used then curl will retry on some HTTP
response codes that indicate transient HTTP errors, but
that does not include most 4xx response codes such as 404.
If you want to retry on all response codes that indicate
HTTP errors (4xx and 5xx) then combine with -f, --fail.
"Knobs? Where we're going, we don't need knobs!" - 14 år med ørene i Lydmaskinen -

Medlemsavatar
Holger
Audio Alchemist
Indlæg: 37634
Sted: Fyn

Indlæg af Holger »

Okay, jeg må lige læse mere op på retry generelt.

Jeg har.dog en mistanke om at mit problem hænger sammen med en et server redirect, så vil prøve -L flag i morgen, når jeg er tilbage fra Sonisk Kollage i Haderslev.

Medlemsavatar
Holger
Audio Alchemist
Indlæg: 37634
Sted: Fyn

Indlæg af Holger »

Meget banalt var forklaring på at --retry-all-errors ikke virkede, at den ikke findes i version 7.68 af cURL, som er den seneste godkendte version i Ubuntu.

Så vil jeg prøve med alm. retry.

Medlemsavatar
Holger
Audio Alchemist
Indlæg: 37634
Sted: Fyn

Indlæg af Holger »

For en høfligheds skyld, så er her min umiddelbare konklusion efter lidt yderligere research:

--retry genprøver kun ved såkaldt transiente fejl, som med curl er defineret som timeout, FTP 4xx response code eller HTTP 5xx.

Det ligner således ikke at det virker med HTTP 4xx, men jeg til mit formål skal benytte --retry-all-errors som ikke findes endnu i min version af curl.

Jeg skal muligvis også inkludere et -f (fail silently) samt altså -L for location (redirect) accept.

Medlemsavatar
amolin
Medlem
Indlæg: 1030

Indlæg af amolin »

Det gir jo fint mening den ikke virker med http 4xx codes, da de betyder "nej, gå væk", generelt fordi en side ikke findes, eller du ikke har adgang til den (og andre lignende client side errors).
5xx errors er server side errors, og så gir det mening at prøve igen (måske senere, afhængig af koden/fejlen).
- Anders
Facebook: [url]http://www.facebook.com/amdrl[/url]
Mit studie: [url]http://beatthemic.com[/url]

Medlemsavatar
Holger
Audio Alchemist
Indlæg: 37634
Sted: Fyn

Indlæg af Holger »

Yes,

Bortset fra at til mit specikke formål der var det tænkt som en "prøv at downloade en fil som ikke er uploadet endnu igen og igen indtil der er bid" og så er 404 netop hvad der dukker op.

Dog er sandsynligheden vel stor for at kommandoen bare får downloadet en delvis fil mens den uploades (måske)... men det hele er eksperimentelt anyways.

Medlemsavatar
amolin
Medlem
Indlæg: 1030

Indlæg af amolin »

Holger skrev: fre 3. sep 2021 22:54 Dog er sandsynligheden vel stor for at kommandoen bare får downloadet en delvis fil mens den uploades (måske)... men det hele er eksperimentelt anyways.
Styrer du selv den side man bruger til upload?
Så får du bare den til at flytte filen til at andet directory efter den er fuldt uploaded, så vil du ikke rende i problemet med at du prøver at downloade en halv fil.
- Anders
Facebook: [url]http://www.facebook.com/amdrl[/url]
Mit studie: [url]http://beatthemic.com[/url]

Nyt svar