Requêtes de plage HTTP : ce que demande un en-tête Range, et ce qui revient

Ce qu’est une requête de plage HTTP

Une requête de plage demande au serveur une partie d’un fichier plutôt que sa totalité. C’est ainsi qu’un lecteur vidéo saute à la vingtième minute sans télécharger les dix-neuf précédentes, qu’un téléchargement reprend après une coupure, et qu’une visionneuse PDF affiche la page 400 d’un gros document sans récupérer les 399 premières. Le client envoie un en-tête Range nommant les décalages d’octets voulus ; le serveur qui accepte répond 206 Partial Content avec ces octets et un en-tête Content-Range indiquant lesquels.

La syntaxe est une unité d’intervalle, un signe égal, puis un ou plusieurs intervalles séparés par des virgules. Une seule unité est définie — bytes — et les décalages sont inclusifs et commencent à zéro : bytes=0-499 désigne donc les cinq cents premiers octets et bytes=500-999 les cinq cents suivants. Le décalage de fin peut être omis, et signifie alors tout ce qui va de là jusqu’à la fin.

La forme qui déroute est celle qui n’a rien avant le tiret. bytes=-500 n’est ni une erreur ni un décalage de moins cinq cents : la spécification l’appelle intervalle de suffixe et le définit, selon ses propres termes, comme les N dernières unités de la ressource. Il demande donc les cinq cents derniers octets, et bytes=0-0,-1 demande le tout premier octet et le tout dernier — l’exemple de la spécification elle-même.

Comment s’en servir

1. Saisissez un en-tête Range et une taille de fichier. L’en-tête s’écrit tel que vous l’enverriez, avec ou sans espaces après les virgules — ceux de la spécification en comportent. La taille est la longueur du fichier entier, car tous les décalages se calculent par rapport à elle.
2. Lisez la ligne de statut. 206 signifie que les plages ont été honorées et 416 qu’aucune ne pouvait l’être, et l’outil affiche le Content-Range que chaque réponse porterait. Les boutons d’exemple couvrent un intervalle de suffixe, un ordinaire, une demande en deux parties et une qui tombe au-delà de la fin.
3. Regardez le tableau. Il liste le premier et le dernier octet exacts de chaque partie qui arriverait, sa taille, et le Content-Range que cette partie porte. En dessous, les constats expliquent ce que la spécification dit de ce que vous avez demandé.

Le serveur a le droit de vous ignorer

C’est la première chose à intégrer, et elle est écrite sans détour : un serveur peut ignorer l’en-tête Range. Ni le refuser ni renvoyer une erreur — l’ignorer, et répondre 200 avec le fichier entier comme si l’en-tête n’avait jamais été envoyé. C’est une réponse conforme, donc tout client qui demande des plages doit savoir recevoir un corps complet plutôt qu’un corps partiel.

La spécification insiste depuis l’autre bord en traitant du 416 : puisque les serveurs sont libres d’ignorer Range, beaucoup d’implémentations répondent avec la ressource entière dans un 200, d’où sa conclusion que les clients ne peuvent pas compter sur un 416, même là où il serait le plus approprié. Si votre logique de reprise traite tout ce qui n’est pas 206 comme un échec, elle cassera face à un serveur parfaitement conforme.

La portée est en outre plus étroite qu’on ne le suppose. La gestion des plages est définie pour exactement une méthode : un serveur doit ignorer un en-tête Range sur une requête dont la méthode lui est inconnue ou pour laquelle aucune gestion de plage n’est définie, et GET est la seule méthode pour laquelle la spécification en définit une. Un Range sur un POST est tenu de ne rien faire.

Une plage et deux plages ne donnent pas la même réponse

Demandez une seule plage et vous obtenez un 206 avec cette plage comme corps et un en-tête Content-Range en tête de réponse indiquant quels octets et sur quel total. Demandez-en deux et la forme change du tout au tout : le serveur doit envoyer du contenu multipart/byteranges, avec un paramètre boundary sur le Content-Type, chaque plage arrivant comme sa propre partie avec ses propres en-têtes.

Et voici la règle qui surprend presque tout le monde, et c’est un MUST NOT, pas une affaire de goût : un serveur ne doit pas placer d’en-tête Content-Range dans la section d’en-têtes d’une réponse à plusieurs parties, car ce champ figure dans chaque partie. Le code qui lit Content-Range sur la réponse pour savoir ce qu’il a reçu ne lira plus rien dès qu’une deuxième plage est ajoutée. L’interdiction joue aussi dans l’autre sens : un serveur ne doit pas emballer une plage unique dans un format multipartie, car un client qui en a demandé une seule pourrait ne pas savoir lire le multipartie.

Deux autres permissions méritent d’être connues avant d’envoyer une longue liste. Un serveur peut fusionner des plages qui se chevauchent, ou séparées par un écart moindre que le coût de les envoyer séparément, et il peut le faire sans respecter l’ordre où elles figuraient dans votre en-tête : ce qui revient n’a donc pas à correspondre à ce que vous avez demandé, ni en nombre ni en ordre. Et le format n’est pas gratuit : la spécification chiffre le surcoût entre parties à environ quatre-vingts octets, et note que transférer beaucoup de petites parties disjointes peut être moins efficace que transférer la ressource entière. L’outil fait l’addition et vous le signale le cas échéant.

Ce que ceci ne vous dira pas

Ceci établit ce que signifie un en-tête. Il ne parle pas à votre serveur. Un navigateur ne peut pas émettre une requête vers une autre origine et vous en relire les en-têtes de réponse sans la coopération de ce serveur : rien n’est donc téléchargé ici, et la taille du fichier est le nombre que vous avez saisi, non une mesure. Pour voir ce que fait un vrai serveur, utilisez le panneau réseau de votre navigateur ou une requête en ligne de commande avec l’en-tête posé à la main.

Il ne peut pas non plus vous dire si le serveur prend en charge les plages. Cela s’annonce par un en-tête Accept-Ranges sur une réponse ordinaire, et comme un serveur peut ignorer Range de toute façon, la seule réponse certaine consiste à demander une plage et à voir ce qui revient. Un 206 signifie oui ; un 200 signifie soit non, soit oui-mais-pas-cette-fois.

Une simplification demeure dans l’arithmétique. Les décalages d’octets en HTTP n’ont pas de plafond, et la spécification prévient explicitement qu’il faut anticiper des nombres décimaux potentiellement énormes et éviter les erreurs de dépassement d’entier. Cette page travaille avec les nombres ordinaires de JavaScript, exacts jusqu’à environ neuf millions de milliards — bien au-delà de tout fichier réel, mais pas illimités : un décalage délibérément gigantesque y perdra donc en précision là où un serveur soigneux n’en perdrait pas.

Enfin, les requêtes de plage conditionnelles sortent du cadre. Une vraie reprise associe d’ordinaire Range à If-Range pour que le serveur vérifie que le fichier n’a pas changé entre-temps et envoie le tout s’il a changé. Cette interaction est un mécanisme distinct avec ses propres règles, et cette page ne répond qu’à la question des octets qu’un Range donné désigne.

Pourquoi est-ce gratuit ?

Analyser un en-tête et faire de l’arithmétique sur des décalages d’octets s’exécute dans votre navigateur. Aucun serveur n’intervient : rien à facturer, aucun compte à créer.

Rien n’est envoyé et rien n’est téléchargé. Rechargez la page et elle aura oublié ce que vous aviez saisi.