Résumé

  • Une réponse 103 contient des champs que le serveur pense retrouver dans sa réponse finale. Le client peut commencer un preload, mais ces champs restent provisoires et ne modifient pas le traitement du statut final.
  • L’émetteur de l’indication, le navigateur qui engage des ressources, la réponse finale et la ressource chargée disposent de pouvoirs distincts. Un gain de temps à une étape ne vaut pas autorisation pour la suivante.

Le serveur connaît déjà la coque habituelle d’une page, mais pas encore son issue. Une lecture de base de données dira si la navigation reçoit le tableau de bord, une redirection d’authentification ou une erreur. Le CDN, lui, conserve l’ancien en-tête qui citait shell.css. Attendre garantit une information fraîche. Prévenir immédiatement peut gagner un aller-retour, au prix d’un téléchargement qui deviendra peut-être inutile.

RFC 8297 donne une forme exacte à ce compromis. Un serveur peut envoyer 103 Early Hints avec un champ Link, poursuivre son calcul puis émettre la réponse finale. Un navigateur peut reconnaître la relation preload et entamer la récupération de la cible pendant cette attente.

Le mécanisme est volontairement faible. Le serveur annonce que certains champs sont probables. Il ne déclare ni le succès de la navigation, ni l’emploi futur de la cible, ni l’identité du contenu qui sera reçu. L’avance temporelle n’est pas un transfert d’autorité.

Une information avant le verdict

RFC 9110 classe 103 parmi les réponses informationnelles 1xx. Une même requête peut recevoir plusieurs réponses intermédiaires, puis une seule réponse finale. Une 1xx s’arrête à la fin de ses champs : elle ne porte ni contenu ni champs de fin. L’agent utilisateur peut ignorer une réponse informationnelle inattendue.

RFC 8297 fixe ensuite la frontière décisive. Le client peut évaluer les champs 103 pour optimiser les performances, mais cette évaluation ne doit pas changer la manière dont il traite la réponse finale. Le statut 200, 302, 404 ou 500 reste le résultat de la requête initiale.

Le silence de 103 ne dit rien non plus. L’origine peut ne connaître à cet instant qu’un seul lien. L’absence d’un champ ne permet pas d’inférer son absence plus tard. Une information partielle n’acquiert pas un pouvoir négatif sur ce qui n’a pas encore été calculé.

La contradiction est même prévue. Plusieurs 103 peuvent annoncer progressivement des champs. La réponse finale peut en reprendre certains, en abandonner un et en introduire un autre. Ce n’est pas une rupture : c’est la raison d’être du statut.

L’origine propose, le client dispose

Quatre décisions se succèdent. L’origine reste propriétaire du statut et des champs finaux. Un intermédiaire de cache peut cependant produire sa propre indication : RFC 8297 donne le cas d’un cache qui utilise les champs d’une réponse périmée pendant une revalidation, avant de transmettre les messages de l’origine.

Le navigateur décide ensuite s’il spécule. Il peut ignorer l’indication, servir la cible depuis son cache, limiter le nombre d’octets, différer le travail ou conclure après une redirection qu’il ne sera pas réutilisé. Link décrit un candidat ; il n’administre pas la file d’attente du client.

La réponse finale tranche la navigation. Une redirection inter-origines, une erreur ou une nouvelle liste de liens peut rendre le travail précoce sans objet. Enfin, la ressource annoncée possède sa propre réalité : résolution DNS, connexion, certificat TLS, identifiants, statut de réponse, type de média, intégrité et politique de cache doivent encore converger.

RFC 8288 définit un lien par son contexte, sa relation, sa cible et ses attributs. Cette phrase structurée n’authentifie pas la cible et ne garantit pas qu’elle pourra être récupérée. La relation preload reste une relation, pas une délégation de pouvoir.

Le Web applique une politique plus étroite

Le standard HTML précise ce que fait un navigateur lors d’une navigation. Le chargement spéculatif peut démarrer avant la réponse documentaire. L’algorithme actuel traite la première indication précoce et l’écarte si une redirection inter-origines suit.

À ce stade, seuls certains attributs sont exploitables : as, crossorigin, integrity et type. D’autres dépendent d’un Document qui n’existe pas encore. Les liens précoces sont examinés avant ceux de la réponse finale et du document, mais l’ordre de traitement ne crée pas une hiérarchie de vérité.

Une politique de sécurité du contenu peut accompagner l’indication et borner la requête précoce. Une politique finale plus stricte peut ensuite empêcher le document d’utiliser une réponse déjà téléchargée. Les octets ont traversé le réseau ; le droit de les employer n’en découle pas.

Le standard Fetch maintient la même discipline : une 103 déclenche le traitement prévu, puis l’algorithme continue d’attendre la réponse finale. L’optimisation demeure enchâssée dans la requête.

Une connaissance périmée peut rester une bonne hypothèse

Le cache intermédiaire montre pourquoi la provenance compte. Le lien de la veille peut très bien prédire la feuille de style d’aujourd’hui. Il peut aussi être faux après un déploiement, une personnalisation ou une redirection. L’étiquette périmé ne supprime pas sa valeur prédictive ; l’étiquette indication empêche cette valeur de devenir autorité présente.

Les journaux doivent donc distinguer l’application, une règle de périphérie et les métadonnées d’une réponse en cache. Ils doivent conserver séparément les champs 103 et finaux. Lorsque deux couches annoncent des cibles différentes, réduire le tout à « le serveur a préchargé » efface précisément la chaîne de responsabilité qu’il faut auditer.

Le coût, lui, n’est pas provisoire

Une mauvaise indication ne corrompt généralement pas la réponse finale. Elle peut néanmoins ouvrir une connexion, révéler un intérêt à un tiers, réveiller une origine, occuper la fenêtre de congestion, consommer une batterie mobile et ralentir le document principal. Une fois la requête envoyée, sa trace et son coût ne peuvent pas être annulés par le statut final.

Le nombre de 103 ne mesure donc rien d’utile à lui seul. Il faut relier réception de l’indication, démarrage anticipé, résultat réseau ou cache, rapprochement avec la réponse finale, acceptation par les politiques et réutilisation réelle par le document. Les millisecondes gagnées doivent être présentées avec les octets, requêtes et connexions dépensés sans usage.

La compatibilité exige aussi des preuves. RFC 8297 avertit qu’un client HTTP/1.1 confondant 103 avec une réponse finale peut mal délimiter les messages suivants d’une connexion persistante et provoquer une divulgation inter-origines. Un serveur peut s’abstenir d’envoyer 103 sur HTTP/1.1 lorsqu’il ne connaît pas le comportement du client. HTTP/2 réduit ce risque de cadrage particulier, sans certifier la pertinence de la prédiction.

Le registre IANA atteste que 103 signifie Early Hints. Il ne démontre ni son passage à travers les intermédiaires, ni l’action d’un navigateur, ni un bénéfice utilisateur.

La doctrine de Lu Heng sur la spécification commune minimale et les décisions localisées trouve ici une expression presque littérale. Le sens partagé reste mince : voici des champs provisoires, une réponse finale suivra. Le choix d’agir appartient au code exécuté chez le participant. La primauté du code en fonctionnement oblige ensuite à vérifier le fil, l’action du client et le résultat, plutôt qu’un simple drapeau de configuration.

Le test de sûreté est simple : supprimer 103 doit dégrader au plus une optimisation. Si la page cesse d’être correcte, la prédiction a déjà pris un pouvoir qu’aucune réponse informationnelle ne lui accordait.