Résumé

  • Le statut 103 transporte des champs que le serveur pense retrouver dans sa réponse finale. Il peut déclencher une préparation réversible, par exemple le préchargement d’une ressource, mais il ne vaut ni décision finale ni promesse.
  • Son bon usage dépend d’un budget de spéculation défini par le client, d’une lecture prudente de la provenance et d’une interdiction claire : aucune opération irréversible ne doit tirer son autorité d’un simple indice anticipé.

Un serveur commence à fabriquer une page. Il sait déjà qu’une feuille de style sera vraisemblablement nécessaire, mais il n’a pas terminé ses calculs, ni peut-être même déterminé le statut final. Il envoie alors 103 Early Hints avec un lien de préchargement. Le navigateur peut exploiter ce temps mort pour demander la feuille de style.

Cette scène paraît élémentaire. Elle révèle pourtant une forme de coordination assez rare : une information peut produire un effet concret avant d’être définitive, sans devenir pour autant une décision. RFC 8297 ne demande pas au client de croire le serveur sur parole. Il lui offre une avance, bornée par la capacité de corriger, d’abandonner ou d’ignorer le travail commencé.

L’exemple le plus important du texte est celui où la prévision change. Deux messages 103 annoncent trois liens possibles. Dans la réponse finale, deux subsistent et le troisième est remplacé. Ce n’est pas une anomalie. C’est la démonstration que le canal est volontairement provisoire.

L’information arrive avant son autorité

Dans HTTP, une même requête peut recevoir plusieurs réponses intermédiaires de la famille 1xx, puis une seule réponse finale qui n’appartient pas à cette famille. RFC 9110 précise que ces réponses intermédiaires n’ont ni contenu ni section de bandes-annonces. Le client doit savoir les analyser, même s’il ne les attend pas ; un agent utilisateur peut néanmoins choisir de les ignorer.

Le statut 103 s’inscrit exactement dans ce cadre. Il signifie que le serveur est susceptible d’inclure dans la réponse finale les champs envoyés par avance. En pratique, il les répète souvent. Mais s’il apprend ensuite qu’un champ était faux, dépassé ou indésirable, il peut le retirer ou le modifier.

La conséquence est nette. Le premier bloc de champs n’est pas une version accélérée de la réponse finale. Il s’agit d’une prévision partielle. RFC 8297 dit que ces champs ne remplacent jamais ceux de la réponse finale et que, hors optimisation des performances, leur évaluation ne doit pas modifier le traitement final.

Une nuance complète ce dispositif : l’absence d’un champ ne dit presque rien. Le serveur peut ne révéler qu’une partie de ce qu’il anticipe. Il peut aussi émettre plusieurs messages 103 au fil de son travail, sans répéter les champs déjà transmis. Ne pas voir une directive de cache ou un lien dans le premier message n’autorise donc pas à conclure qu’elle sera absente ensuite.

Cette dissymétrie est saine. La présence d’un indice permet une action limitée ; le silence ne permet pas de construire une politique négative. Une implémentation qui fusionnerait immédiatement tous les champs intermédiaires dans un faux en-tête final effacerait cette propriété.

Précharger n’est pas obéir

Le cas d’usage canonique repose sur le champ Link et la relation preload. Le lien indique qu'une ressource pourrait être utile au traitement ultérieur. Un agent capable peut commencer à la télécharger pendant que la réponse principale se prépare.

Le mot « peut » compte davantage que le gain de quelques millisecondes. Le client conserve la décision. Il peut ne pas reconnaître la relation, refuser les cibles hors origine, limiter les octets spéculatifs, tenir compte d’un réseau coûteux ou désactiver le mécanisme après une régression. L’interopérabilité porte sur le sens du signal, non sur l’obligation d’engager les mêmes ressources partout.

Une requête anticipée reste une vraie requête. Elle consomme de la bande passante, peut chauffer un cache, ouvrir une connexion et révéler un intérêt pour une adresse. Selon le contexte, elle peut aussi porter des informations d’identification régies par les règles normales du Web. L’arrivée précoce du champ n’assouplit ni la politique d’origine, ni le mode de requête, ni les contrôles d’accès.

Il faut donc distinguer le caractère réversible du caractère familier. Charger en avance un fichier statique public et de taille bornée peut être une spéculation acceptable. Réserver définitivement un produit, envoyer un secret, déclencher un paiement ou notifier un tiers ne le devient pas parce qu’un lien a été reçu dans une réponse 103.

La règle de gouvernance tient en une phrase : l’indice permet d’avancer le temps d’une opération déjà permise ; il ne fabrique pas la permission.

La provenance traverse les intermédiaires

Le client ne doit pas supposer que tous les messages précoces proviennent du même acteur. RFC 8297 décrit le cas d’un cache intermédiaire qui génère un 103 à partir des champs d’une réponse périmée. Pendant la revalidation, il peut ensuite relayer un autre 103 et la réponse finale de l’origine.

Ce comportement rend l’optimisation plus efficace : le point de présence proche du lecteur dispose parfois d’assez d’information pour agir sans attendre l’application. Il rend aussi la provenance plus complexe. Un champ observé tôt ne prouve pas que l’application d’origine vient de l’émettre, ni qu’elle le maintiendra.

RFC 9110 impose en général aux mandataires de relayer les réponses 1xx, sauf lorsqu’ils ont eux-mêmes demandé la génération de la réponse intermédiaire concernée. Cette règle décrit la circulation du message. Elle ne transforme ni le relais ni le générateur intermédiaire en autorité sur le résultat final.

Pour l’exploitation, la chaîne doit être documentée : quel composant peut synthétiser un 103, à partir de quel état de cache, pendant combien de temps et avec quelle stratégie de correction ? Une passerelle qui prévoit un lien à partir d’une observation ancienne doit être mesurée comme un prédicteur, pas traitée comme une source infaillible.

Le client, lui, ne recevra pas toujours une attestation complète de cette chaîne. Sa politique doit donc rester sûre même lorsque l’auteur exact de l’indice n’est pas démontré. Plus l’action envisagée est sensible, moins un signal à provenance ambiguë peut suffire.

La frontière intermédiaire/final protège aussi les messages

RFC 8297 attire l’attention sur un échec particulier sous HTTP/1.1. Certains clients anciens ou défectueux peuvent prendre la réponse 103 pour la réponse finale. Sur une connexion persistante, ils risquent alors d’associer les réponses aux requêtes suivantes au mauvais message. Si plusieurs origines partagent la connexion, cette confusion peut révéler des informations entre origines.

Le problème montre que « provisoire » n’est pas une simple étiquette éditoriale. C’est une propriété de délimitation. RFC 9112 demande au client d’associer les messages reçus à la première requête en attente qui n’a pas encore obtenu de réponse finale. Une ou plusieurs réponses 1xx peuvent précéder cette fin. Perdre la distinction revient à perdre la structure de la conversation.

Le texte expérimental suggère donc qu’un serveur peut éviter d’envoyer 103 sous HTTP/1.1 lorsqu’il ne sait pas si le client gère correctement les réponses informationnelles. Il estime le risque de mauvais cadrage moins probable sous HTTP/2, où les champs d’une réponse intermédiaire occupent des trames rattachées à un flux et ne peuvent pas en marquer la fin. HTTP/3 conserve lui aussi la séquence de réponses intermédiaires avant la réponse finale, sans contenu ni bandes-annonces dans les 1xx.

Ces protocoles réduisent une classe d’erreurs. Ils ne résolvent pas l’abus sémantique. Un client HTTP/3 peut interpréter parfaitement toutes ses trames, puis commettre une faute de gouvernance en confondant indice et consentement. Le transport préserve les frontières ; l’application doit encore les respecter.

Le cache est une mémoire, pas un arbitre

Les caches rendent les indices rapides parce qu’ils possèdent déjà une image du passé. Or cette image peut être périmée. Une réponse précédente contenait peut-être une feuille de style que la nouvelle page n’utilisera plus. La revalidation peut échouer ou aboutir à un autre statut.

Les règles de cache HTTP distinguent la fraîcheur, la validation, le stockage et la réutilisation de la réponse finale. L’existence d’un préchargement déclenché par 103 ne décide d’aucune de ces questions. Le fait qu’un objet se trouve désormais en cache ne prouve ni que la page finale le référencera, ni que le client aura le droit de l’utiliser.

Il est utile de conserver cinq événements séparés : indice émis, indice reçu, chargement commencé, champ confirmé dans la réponse finale, ressource effectivement consommée. Une seule mesure de « réussite 103 » masquerait les octets gaspillés, les doublons, les mauvaises cibles et les divergences entre la périphérie et l’origine.

Le vrai budget est réparti. Le site profite d’un rendu potentiellement plus rapide ; l’utilisateur paie les données inutiles ; l’origine absorbe les requêtes supplémentaires ; l’intermédiaire mobilise connexions et mémoire. Ces intérêts ne coïncident pas toujours. Voilà pourquoi le destinataire doit pouvoir limiter l’action, plutôt que recevoir une commande uniforme.

Un standard minimal laisse plusieurs politiques légitimes

RFC 8297 est un document expérimental de l’IETF, publié après consensus, examen public et approbation de l’IESG. Ce statut compte : il ne faut pas le présenter comme une norme du Standards Track ni comme un mandat de déploiement universel. Le registre IANA attribue néanmoins au code 103 un nom commun et renvoie vers ce document.

Le socle partagé reste volontairement petit : un code informationnel, des champs HTTP ordinaires, une place avant la réponse finale et une interdiction de leur donner l’autorité de celle-ci. Sur cette base, les politiques locales peuvent différer sans rendre le message incompréhensible.

Un navigateur grand public peut reconnaître certains liens de préchargement. Un terminal contraint peut tout ignorer. Une entreprise peut refuser la spéculation vers un domaine tiers. Un cache peut émettre des indices uniquement lorsque sa prédiction a récemment été confirmée. Chacun demeure compatible avec le protocole.

La méthode rejoint la proposition de Lu Heng : une spécification initiale minimale, puis des décisions futures prises localement et une adoption volontaire éclairée par les effets observés. Le serveur choisit ce qu’il sait raisonnablement prévoir. L’intermédiaire choisit si son état mérite confiance. Le client choisit ce qu’il est prêt à dépenser avant la certitude.

Centraliser chaque autorisation contredirait l’objectif de latence. Cela ne signifie pas que l’action est sans règle. Les règles sont préparées à l’avance au bon endroit : liste de relations comprises, plafond de coût, origines admises, gestion des informations d’identification et opérations explicitement interdites.

Tenir un registre de spéculation

Une mise en œuvre responsable ne crée pas une « réponse finale provisoire ». Elle garde une trace ordonnée des messages 103 et de la réponse finale. Elle sait quel bloc a déclenché quelle action et conserve les modifications au lieu d’écraser le premier état par le dernier.

Elle classe ensuite les effets. Une ressource publique, annulable et bornée peut entrer dans le budget. Une modification d’état, une divulgation de secret, une décision d’accès ou un engagement financier en sort. Le classement porte sur l’effet réel, pas seulement sur le nom du champ.

À l’arrivée de la réponse finale, le système réconcilie les prévisions : champs répétés, omis ou remplacés ; tâches encore utiles ou à annuler ; octets gagnés ou perdus. Le traitement de la réponse suit les champs finaux. L’historique des indices reste disponible pour comprendre la performance et les erreurs.

Enfin, la possibilité de ne rien faire demeure un élément du contrat. Un agent utilisateur peut ignorer une réponse 1xx inattendue. Une exploitation qui découvre un risque doit pouvoir couper l’action anticipée sans casser le traitement normal des réponses finales.

Early Hints ne promet pas de connaître l’avenir. Il organise l’incertitude pour qu’un acteur puisse prendre une petite avance sans recevoir un pouvoir excessif. C’est un modèle de coordination plus large que le Web : partager tôt ce qui est utile, borner le coût d’une erreur, puis laisser la décision achevée garder son autorité.

Sources