El manual de curl indica que los códigos HTTP de error no se consideran fallos de transferencia por defecto. Un script puede recibir un documento de error y tratar la operación como exitosa. Esta revisión aborda el comportamiento documentado; YNIX no ha probado tu API ni medido fiabilidad.

En HTTP, --fail devuelve el error 22 para respuestas de 400 en adelante y suprime el cuerpo. El manual advierte de excepciones, especialmente en autenticación con 401 y 407. La aplicación debe comprobar además el estado y contenido que espera recibir.

La alternativa --fail-with-body conserva el cuerpo de error y devuelve un fallo. No puede combinarse con --fail y apareció en curl 7.76.0. Comprueba la versión instalada antes de cambiar automatizaciones. Separa los cuerpos de diagnóstico de los archivos que otra tarea pueda consumir como salida válida.

Conclusión: estas opciones sirven si el programa que llama a curl gestiona el fallo. Con varias transferencias, --fail-early detecta errores tempranos, pero no activa por sí mismo el fallo por estado HTTP. Usa un destino temporal, comprueba estado de salida y contenido esperado y solo después acepta el archivo. Un archivo no vacío no demuestra una descarga válida.