Reprendre un téléchargement à travers Squid
Vérifiez les réponses Range et l’identité de l’objet avant de reprendre un fichier, et distinguez le préchargement Squid de la prise en charge de Range.
N’utilisez la reprise que si download.part appartient à la même représentation d’objet que celle demandée maintenant. Le nom de fichier ne suffit pas : l’origine peut avoir changé le contenu depuis la première tentative.
curl --proxy http://proxy.example:3128 --noproxy '' --connect-timeout 5 --max-time 60 -C - --output download.part http://files.example/test.binRemplacez les deux points de connexion par des services que vous êtes autorisé à utiliser. Pour comparer un fichier public lorsque les proxys publics sont permis, choisissez un point HTTP dans la liste de proxys HTTP. -C - utilise la taille du fichier existant comme point de reprise. Examinez la réponse de destination au lieu de considérer tout corps reçu comme les octets manquants :
| Réponse | Interprétation |
|---|---|
| 206 avec Content-Range | Vérifiez que la plage reçue correspond à la reprise attendue. |
| 200 | Le serveur peut avoir ignoré Range et envoyé toute la représentation. |
| 416 | La plage demandée ne peut pas être satisfaite ; n’ajoutez pas la page d’erreur au fichier. |
Les validateurs et If-Range peuvent éviter d’assembler des versions différentes d’une ressource changeante. Suivez les règles de représentation de l’application avant de faire confiance au fichier terminé.
Dans Squid 6.13, range_offset_limit détermine quand récupérer un objet depuis le début pour le mettre en cache, pas si le client peut demander une plage :
range_offset_limit 0Une limite à zéro évite de récupérer un préfixe supplémentaire uniquement pour remplir le cache. Transmettre une plage utile sans mettre l’objet en cache peut tout à fait réussir. Avec un CONNECT HTTPS ordinaire, l’échange Range se trouve dans le TLS de destination ; lisez cette réponse plutôt que de traiter la politique de cache objet visible de Squid comme une commande de la requête interne.