Tecnología · GUÍA PRÁCTICA
¿Error 18 de curl? Demuestra los bytes faltantes antes de reintentar o reanudar
CURLE_PARTIAL_FILE significa que el tamaño recibido no coincidió con el tamaño anunciado. Conserva el archivo parcial, las cabeceras y la traza; aísla el encuadre, el protocolo y el intermediario antes de reiniciar o reanudar con un validador.
El error 18 de curl demuestra una diferencia de tamaño; no identifica una única causa de red. El proyecto curl define CURLE_PARTIAL_FILE como una transferencia más corta o más larga que el tamaño comunicado previamente.
No sobrescribas el primer archivo parcial ni actives reintentos de inmediato. Registra el encuadre, los bytes recibidos y la identidad de la representación para probar servidor, proxy, protocolo y ruta del cliente por separado.
1. Congela la primera evidencia
Mueve la salida parcial a un archivo de evidencia único y registra tamaño y resumen. Guarda versión y funciones de curl, comando sin secretos, horas, código de salida, URL, proxy y si lo ejecutó un contenedor, CI o envoltorio.
Captura una sola vez hacia un archivo nuevo: cabeceras por separado y traza con tiempo, eliminando Authorization, Cookie, consultas firmadas y certificados. Un reintento puede llegar a otro servidor o a otra representación.
2. Lee el encuadre antes de culpar a la red
En HTTP/1.1, si Transfer-Encoding termina en chunked, hace falta el bloque final de tamaño cero. Sin Transfer-Encoding y con Content-Length válido, ese número es la longitud esperada; cerrar antes es incompleto según RFC 9112.
gzip y br son codificación de contenido; chunked es encuadre de transferencia. Cambiar Accept-Encoding o la versión HTTP sirve para aislar una rama, pero no arregla por sí solo una longitud errónea, un origen truncado o un intermediario roto.
3. Cambia una sola frontera cada vez
Escribe cada prueba en un destino nuevo y cambia solo una variable: origen directo o CDN, IPv4 o IPv6, HTTP/1.1 o HTTP/2/3, compresión o identity. Anota estado, URL efectiva, protocolo, longitud declarada, bytes, salida y resumen.
Que una ruta funcione no prueba otra. Si el origen funciona y el proxy trunca, conserva ambas trazas; si todas fallan en el mismo byte, revisa la aplicación, tiempos de espera, generación de Content-Length y lecturas de almacenamiento.
4. Decide si los bytes parciales sirven
No aceptes solo un 200. Exige salida 0 de curl, final del encuadre o tamaño esperado, y una señal de integridad como checksum, firma, prueba de archivo o parser. Una página HTML con nombre binario sigue siendo un fallo.
En API valida también el efecto. Un POST no idempotente puede haberse confirmado aunque la respuesta se corte. Comprueba clave de idempotencia, identificador de transacción o endpoint de estado antes de repetir.
5. Reanuda solo con un contrato probado
Reanuda únicamente si el servidor admite el rango necesario y ETag o Last-Modified prueban que la representación no cambió. Verifica que devuelve el estado parcial y el rango esperados.
Si el validador falta, es débil o cambió, empieza en un destino nuevo y no anexes a ciegas. Cierra el incidente solo cuando salida, encuadre, bytes e integridad pasan y la ruta defectuosa fue reparada o retirada.
