Résumé

  • Le statut HTTP 206 confirme la livraison d’une ou plusieurs plages déclarées d’une représentation sélectionnée ; il ne prouve pas que des plages obtenues séparément forment un objet complet.
  • Une reprise ou un assemblage en cache doit conserver un même validateur fort, une couverture exacte des intervalles et une vérification finale au niveau de la représentation.
  • Dans une réponse 206, Content-Length mesure normalement le corps du message présent, tandis que Content-Range situe les octets et indique la longueur complète de la représentation.
  • Une preuve d’assemblage doit préserver l’identité de version et chaque plage acceptée, au lieu de confondre compteur d’octets et intégrité.

Imaginons le téléchargement d’une archive de données de routage depuis un stockage d’objets. La connexion s’interrompt à mi-parcours. Avant la reprise, l’origine remplace l’archive par un export plus récent de même taille apparente. Les deux requêtes renvoient 206, toutes les plages demandées arrivent et le compteur atteint la longueur attendue. Pourtant, le fichier final juxtapose le début d’une version et la fin d’une autre : aucun validateur fort n’a lié les deux échanges.

Il s’agit d’un scénario hypothétique, non d’un incident attribué à un fournisseur. HTTP fournit les mécanismes nécessaires. L’erreur opérationnelle consiste à demander au statut de plage une preuve qu’il ne porte pas.

Le succès d’une plage reste une preuve limitée

La RFC 9110 définit 206 Partial Content comme l’exécution réussie d’une requête de plage par le transfert d’une ou plusieurs parties de la représentation sélectionnée. Le serveur affirme donc avoir fourni les intervalles décrits. Il n’affirme pas que le client possède désormais la représentation entière.

Le destinataire doit examiner Content-Type et chaque champ Content-Range pour savoir quelles parties sont présentes et si d’autres requêtes sont nécessaires. Pour une plage unique, Content-Range donne l’intervalle inclusif et, le plus souvent, la longueur totale. Content-Length compte les octets du contenu de cette réponse 206. Les confondre transforme une réponse correcte en faux signal d’achèvement.

Avec plusieurs plages, l’ordre de retour peut différer de l’ordre demandé ; le serveur peut fusionner des intervalles ou écarter ceux qui ne sont pas satisfaisables. La couverture doit donc être calculée à partir des plages reçues, et non du nombre de réponses ou d’une barre de progression.

La continuité porte sur la représentation, pas sur l’URL

Une URL stable ne garantit pas des octets stables. Une mise en production, la négociation de contenu, l’heure de génération ou une mise à jour de l’origine peuvent changer la représentation sans changer la cible. Une reprise sûre exige que les fragments anciens et nouveaux appartiennent à la même version.

If-Range protège précisément cette frontière. Le client envoie sa requête de plage avec un validateur. S’il correspond encore, le serveur peut fournir la partie demandée. S’il ne correspond plus, le serveur ignore Range et renvoie la nouvelle représentation entière. La RFC 9110 interdit l’usage d’un ETag faible dans If-Range : la comparaison doit distinguer les représentations aptes à être combinées octet par octet.

Un 200 reçu après If-Range n’est donc pas un échec d’optimisation à contourner. Il indique que l’ancien fragment ne peut plus être prolongé sans risque. Le client doit abandonner cet état d’assemblage et accepter la nouvelle représentation complète.

Un cache hérite de la même obligation

La RFC 9111 permet à un cache de compléter une réponse inachevée par des requêtes de plage. Elle n’autorise toutefois la combinaison que si toutes les plages partagent le même validateur fort et si les règles de combinaison sont respectées.

Le taux de succès du cache et le volume stocké ne suffisent donc pas. Il faut connaître la clé de cache et les champs de négociation, le validateur de chaque intervalle, la mise à jour des en-têtes et l’état frais, revalidé ou explicitement périmé de la réponse assemblée. Un gestionnaire de téléchargement, un miroir ou une passerelle de stockage rencontre le même problème dès qu’il conserve des fragments, même s’il ne se présente pas comme un cache.

Vérifier la bonne étendue d’intégrité

La RFC 9530 distingue Content-Digest, calculé sur le contenu d’un message HTTP, et Repr-Digest, calculé sur les données de la représentation sélectionnée entière. Pour une réponse 206, l’empreinte du contenu peut vérifier le segment reçu ; l’empreinte de représentation peut vérifier l’objet recomposé au fil de plusieurs requêtes ou connexions.

Ces empreintes ne remplacent pas le validateur. Le validateur établit la continuité de version ; Repr-Digest vérifie les octets finaux ; la table d’intervalles montre qu’aucun trou ni chevauchement n’est masqué par un total. Les champs d’intégrité ne définissent par ailleurs ni authentification, ni autorisation, ni confidentialité. R063 reste sur une question plus étroite : les octets reçus forment-ils une seule représentation cohérente ?

Établir un reçu d’assemblage

Le reçu d’assemblage démarre avec la première plage acceptée. Il fixe l’URI cible, la méthode, les en-têtes qui influencent la sélection, l’encodage, le type de média, la longueur complète, le validateur fort, l’heure et la provenance — origine, intermédiaire ou stockage local.

Pour chaque partie, il conserve l’intervalle réellement renvoyé, le statut, le validateur, la source, l’état du cache et, si possible, l’empreinte du segment. Une liste normalisée empêche les chevauchements de gonfler l’avancement et laisse les lacunes visibles. Tout fragment dont le validateur ou les métadonnées divergent est refusé.

Le reçu ne se ferme que lorsque les intervalles couvrent exactement la représentation et que les octets recomposés satisfont le Repr-Digest attendu ou une empreinte obtenue indépendamment. Si le validateur change, disparaît ou devient ambigu, le bon choix est de reprendre l’objet entier. Ce coût de bande passante protège une affirmation plus précieuse : l’objet traité a réellement existé sous une forme cohérente.

Sources