Reanudar descargas a través de Squid
Comprueba las respuestas Range y la identidad del objeto antes de reanudar, y distingue la precarga de Squid del soporte básico de rangos.
Usa la reanudación solo si download.part pertenece a la misma representación del objeto que vas a solicitar ahora. El nombre del archivo no basta: el origen puede haber cambiado el contenido desde el primer intento.
curl --proxy http://proxy.example:3128 --noproxy '' --connect-timeout 5 --max-time 60 -C - --output download.part http://files.example/test.binSustituye ambos puntos de conexión por servicios que tengas permiso para usar. Para comparar un archivo público donde se permitan proxies públicos, toma un punto HTTP de la lista de proxies HTTP. -C - usa el tamaño del archivo existente como punto de reanudación. Inspecciona la respuesta del destino en vez de considerar cualquier cuerpo recibido como los bytes que faltan:
| Respuesta | Interpretación |
|---|---|
| 206 con Content-Range | Comprueba que el rango devuelto sea la continuación esperada. |
| 200 | El servidor puede haber ignorado Range y enviado la representación completa. |
| 416 | El rango solicitado no puede satisfacerse; no añadas la página de error al archivo. |
Los validadores y If-Range pueden ayudar a evitar unir versiones de un recurso cambiante. Sigue las reglas de representación de la aplicación antes de confiar en el archivo completado.
En Squid 6.13, range_offset_limit controla cuándo se obtiene un objeto desde el principio para almacenarlo en caché, no si el cliente puede pedir un rango:
range_offset_limit 0Un límite de cero evita obtener un prefijo adicional solo para llenar la caché. Reenviar un rango útil sin guardar el objeto en caché puede seguir siendo correcto. En CONNECT HTTPS normal, el intercambio Range está dentro del TLS del destino; lee esa respuesta en lugar de tratar la política visible de caché de objetos de Squid como control de la petición interna.