Servir les requêtes de plage pour des téléchargements reprenables

Objectif

Permettre aux clients de reprendre des transferts interrompus de fichiers volumineux et d'en récupérer des parties sans tout télécharger, d'une manière que les intermédiaires comprennent.

Prérequis

Des fichiers servis comme des représentations stables avec un ETag fort et un Last-Modified, et sans Content-Encoding calculé à la volée : les plages d'octets s'appliquent à la représentation encodée, de sorte qu'une réponse compressée par requête n'a pas de décalages stables. La prise en charge des plages est optionnelle, chaque client doit donc pouvoir composer avec un 200 complet à la place.

Étapes

1. Envoyer Accept-Ranges: bytes et un ETag fort sur les réponses complètes pour les ressources téléchargeables ; cet en-tête invite les clients à essayer des plages.
2. N'honorer Range que sur GET, la seule méthode pour laquelle la gestion des plages est définie. Ignorer les unités de plage inconnues. La RFC 9110 autorise à ignorer ou à rejeter des spécificateurs invalides, des plages qui se chevauchent ou de nombreuses petites plages non ordonnées, comme défense contre le déni de service.
3. Évaluer d'abord les préconditions : un GET conditionnel qui produit un 304 ignore Range. Évaluer ensuite If-Range : une étiquette d'entité doit correspondre selon une comparaison forte (les clients NE DOIVENT PAS y envoyer d'étiquettes faibles), une date HTTP doit correspondre exactement à Last-Modified ; si la condition échoue, ignorer Range et envoyer le 200 complet.
4. Pour une plage satisfaisable unique, répondre 206 Partial Content avec Content-Range: bytes 500-999/1234, un Content-Length égal à la partie, et les mêmes ETag, Content-Type, Last-Modified et Cache-Control que la réponse complète.
5. Pour plusieurs plages, construire un corps multipart/byteranges avec un Content-Range par partie ; la RFC 9110 permet à un serveur de fusionner des plages qui se chevauchent ou sont presque adjacentes, et de n'envoyer qu'un sous-ensemble de ce qui a été demandé.
6. Lorsqu'aucune plage n'est satisfaisable, par exemple une position de départ au-delà de la longueur, répondre 416 Range Not Satisfiable avec Content-Range: bytes */1234. Une plage de suffixe plus longue que le fichier (bytes=-500 sur 300 octets) produit la représentation entière.
7. Côté client : conserver l'ETag de la première réponse ; pour reprendre, envoyer Range: bytes=<received>- avec If-Range: "<etag>" ; sur un 206, vérifier que la première position de Content-Range correspond au décalage local avant d'ajouter les données ; sur un 200, jeter le fichier partiel et recommencer.
8. Tester avec curl -r 0-99 -D - URL, une reprise (curl -C - -O URL), une requête après remplacement du fichier, et bytes=0-0,-1 pour le multipart.

Résultat attendu

Les téléchargements interrompus reprennent au décalage d'octet exact ; un fichier remplacé entre deux tentatives est récupéré à nouveau depuis le début plutôt que d'être recollé ; les caches qui implémentent les plages répondent à une sous-plage à partir d'une copie stockée, ce que la RFC 9111 autorise même depuis une copie incomplète si la plage y est entièrement contenue.

Limites et base de vérification

Le contenu généré ou négocié nécessite une représentation stable par variante. Un 206 peut provenir du cache d'un intermédiaire ; la RFC 9111 interdit à un cache de stocker des réponses partielles dont il ne comprend pas l'unité de plage. Les étapes suivent les spécifications citées ; aucun chiffre de débit ou de taux d'échec n'est avancé.