Le manuel curl précise que les codes HTTP d’erreur ne constituent pas par défaut des échecs de transfert. Un script peut donc recevoir un document d’erreur tout en considérant le transfert réussi. Cette revue porte sur le comportement documenté, sans test de votre API ni mesure de fiabilité par YNIX.

Pour HTTP, --fail renvoie l’erreur 22 à partir du code 400 et supprime le corps de réponse. Le manuel signale des exceptions, particulièrement avec l’authentification et les réponses 401 ou 407. L’application doit également vérifier le statut et le contenu attendus.

L’alternative --fail-with-body conserve le corps d’erreur tout en signalant un échec. Incompatible avec --fail, elle existe depuis curl 7.76.0. Vérifiez la version installée avant de modifier un automatisme. Séparez les diagnostics des fichiers qu’une tâche suivante pourrait prendre pour un résultat valide.

Verdict : ces options sont utiles si le script appelant traite effectivement les échecs. Pour plusieurs transferts, --fail-early détecte les erreurs précoces mais n’active pas seul l’échec selon le statut HTTP. Écrivez dans une destination temporaire, vérifiez le code de sortie et le contenu, puis acceptez le résultat. Un fichier non vide ne prouve pas un téléchargement valide.