Résumé

  • Une réponse 103 est provisoire : elle autorise une préparation pendant que le serveur construit encore sa réponse finale.
  • Les champs annoncés peuvent changer et l’état final peut être un succès, une redirection, une erreur client ou une erreur serveur.
  • Un lien de préchargement décrit une relation ; il ne prouve ni la réussite du téléchargement, ni l’autorisation d’utiliser la cible.
  • La supervision doit conserver toute la chaîne de réponses et l’issue de chaque opération spéculative avant de conclure à la disponibilité.

Imaginons un tableau de livraison qui retient le premier code reçu. Le frontal émet 103 Early Hints avec deux liens de préchargement ; le voyant passe au vert. La même requête se termine ensuite par 503 Service Unavailable, tandis qu’une ressource anticipée échoue. Le 103 était authentique et utile pour tenter de gagner du temps. La conclusion de disponibilité, elle, était fausse.

RFC 8297 introduit Early Hints pour exploiter l’attente pendant laquelle l’origine prépare sa réponse finale. Le client peut ouvrir une connexion ou demander une feuille de style probable. Cette avance a de la valeur précisément parce qu’elle intervient avant que le résultat soit connu.

Le texte indique que le serveur enverra probablement les champs annoncés dans la réponse finale. Il les répète normalement, mais peut découvrir qu’un champ précoce était erroné ou devenu inopportun. Il est donc légitime que la réponse finale diffère. Une mesure qui ne stocke que le 103 efface l’incertitude que le protocole conserve volontairement.

Les champs du 103 ne remplacent pas ceux de la réponse finale. En dehors de l’optimisation des performances, leur traitement ne doit pas modifier la façon dont le client traite le résultat final. Le préchargement prépare ; il n’accorde pas l’accès, ne choisit pas la représentation et ne transforme pas une réponse à venir en succès.

RFC 9110 donne le modèle complet : une requête peut recevoir zéro, une ou plusieurs réponses informationnelles 1xx, puis une seule réponse finale hors de cette classe. Les familles de codes ne sont pas interchangeables. 1xx décrit une progression, 2xx un succès, 3xx une redirection, 4xx une erreur côté client et 5xx un échec côté serveur.

Même un 200 final ne décrit pas nécessairement toute l’expérience. Le document principal peut référencer une ressource qui échoue, arrive trop tard, ne passe pas le contrôle d’intégrité ou est refusée par une politique. Une sonde anonyme peut recevoir autre chose qu’une session authentifiée. Il faut rattacher la chaîne HTTP au résultat que l’exploitation cherche réellement à garantir.

RFC 8288 définit les liens web comme des relations typées entre une ressource de contexte et une cible. Un champ Link de type preload peut nommer une cible et une manière de la préparer. Il ne certifie pas la résolution DNS, l’établissement de connexion, TLS, l’autorisation, l’éligibilité au cache, l’intégrité de l’objet ou la réussite du transfert.

Le point d’observation compte aussi. Un navigateur, un CDN, un proxy inverse ou une sonde qui voit un 103 prouve seulement que cette réponse provisoire a traversé cette chaîne vers cet observateur. Il ne permet pas d’attribuer automatiquement chaque champ à l’origine, ni de prédire le comportement d’une autre région, d’un autre protocole, d’un cache froid ou d’une autre identité.

La spéculation a un coût. Une cible inutile consomme bande passante, connexions, énergie et capacité de cache. RFC 8297 encadre le traitement des champs précoces parce qu’une optimisation peut avoir des effets de sécurité et de confidentialité. L’objectif n’est pas d’abandonner Early Hints, mais de rendre le périmètre et le coût vérifiables.

Un reçu de chaîne HTTP devrait enregistrer la méthode, la cible, le protocole, la connexion et le point d’observation ; chaque réponse provisoire dans l’ordre ; l’état et les champs finaux ; ainsi qu’une empreinte de la représentation lorsque c’est possible. Pour chaque cible spéculative, il conserverait la relation, le 103 déclencheur, le mode d’envoi des identifiants, le cache, le résultat, l’intégrité et la durée. L’identité de l’intermédiaire, le contexte d’autorisation et l’heure complètent le reçu sans révéler de secret.

Le vocabulaire du tableau de bord devient alors plus honnête. « 103 observé », « préchargement lancé », « 200 final reçu », « représentation vérifiée » et « transaction applicative achevée » sont cinq événements. Ils peuvent alimenter une même vue, mais le premier ne doit pas fabriquer les quatre suivants.

Cette séparation aide aussi au diagnostic. Une amélioration du délai du 103 accompagnée d’une dégradation de la réponse finale pointe vers le travail applicatif tardif. Un échec limité à une région peut relever du chemin ou du cache. Une différence entre liens précoces et finaux peut révéler une décision tardive de routage, de contenu ou d’autorisation. Les propriétaires ne sont pas les mêmes.

Early Hints reste donc un signal précieux : il montre qu’une chaîne HTTP observée a atteint le moment où des relations provisoires pouvaient être communiquées. Il révèle la spéculation gaspillée et les divergences d’infrastructure. Il ne peut promettre une réponse qui, par définition, n’est pas encore finale.

Sources

RFC 8297 — An HTTP Status Code for Indicating Hints; RFC 9110 — HTTP Semantics; RFC 8288 — Web Linking.