Résumé

  • Le RFC 3229 étend la requête GET conditionnelle: le client nomme ses anciennes instances avec If-None-Match, annonce les transformations acceptées dans A-IM, puis peut recevoir 226 et une recette IM au lieu d'une copie entière.
  • La reconstruction possède trois identités. Delta-Base désigne l'ancienne base, le corps transporte la différence et l'ETag de la réponse désigne la nouvelle instance reconstruite — jamais les octets du delta.
  • Le nouveau code protège aussi les anciens caches. Ignorer un en-tête inconnu pouvait les conduire à stocker une différence comme si elle était le document complet; 226 rendait cette rupture sémantique visible.

Le cache économisait tout ou rien

La validation conditionnelle avait déjà supprimé de nombreuses répétitions. Si la copie conservée était encore actuelle, 304 Not Modified suffisait. Dès qu'elle changeait, même légèrement, la réponse normale redevenait l'instance complète.

Le cache servait donc de témoin binaire: parfaitement réutilisable ou inutile pour le transfert. Une correction minuscule pouvait imposer le renvoi de toutes les parties inchangées.

Publié en janvier 2002, le RFC 3229 transforme l'ancienne copie en matière de reconstruction. Le serveur peut calculer la différence entre une base connue du client et l'instance courante, puis n'envoyer que cette différence.

La proposition reste facultative et vise une réduction moyenne sans aller-retour supplémentaire. Elle ne promet ni une économie pour chaque ressource ni la disponibilité éternelle des versions anciennes.

La différence n'est ni une compression ni une tranche

Le texte définit l'« instance » comme ce qu'un GET 200 renverrait pour la variante choisie après codage de contenu, mais avant manipulation d'instance et codage de transfert.

Une compression se décode à partir de ses propres octets. Un delta a généralement besoin d'une base particulière. Une plage sélectionne des coordonnées dans l'instance courante; un delta explique comment passer d'une instance à une autre. Les deux réduisent le corps, mais pas selon la même preuve.

Le delta n'est pas davantage un PATCH. Le corps 226 répond à GET et sert à retrouver l'état courant côté destinataire. Il ne commande aucune mutation de la ressource. Le RFC 3229 ne spécifie ce mécanisme que pour les réponses à GET.

Ces distinctions empêchent le mot « différence » de devenir une catégorie vague où toute réduction d'octets semblerait interchangeable.

Le client devait annoncer ce qu'il possédait

If-None-Match énumère un ou plusieurs ETag d'instances antérieures présentes chez le client. A-IM annonce les manipulations qu'il sait appliquer.

Si l'ETag est encore celui de l'instance courante, la branche traditionnelle 304 reste la bonne. Si l'état a changé, un serveur capable peut choisir une base proposée et calculer un delta compatible. S'il ne possède plus cette base, ignore le format ou juge le calcul inutile, il peut renvoyer 200.

Le client fait donc une offre, pas une injonction. Il contrôle la liste des bases disponibles et des algorithmes exécutables. L'origine contrôle la conservation des versions, le coût du calcul et le choix de transmettre le tout.

Avant d'envoyer une « différence », les deux côtés doivent partager la réponse à deux questions: différence par rapport à quoi, et selon quelle opération ?

Trois objets traversent une seule réponse

La base est l'ancienne instance gardée en cache. Le corps 226 contient les instructions de transformation. Le résultat de leur application est l'instance courante.

Quand le client a fourni plusieurs ETag, Delta-Base précise lequel le serveur a choisi. L'ETag de la réponse nomme le résultat courant. Le RFC insiste: cet ETag ne peut pas être celui du delta, car le delta n'est pas une instance autonome.

Cette séparation est le centre de l'architecture. Un corps peut être parfaitement correct et pourtant inutilisable seul. Sa signification dépend d'une base exacte, d'une transformation exacte et d'une identité de sortie.

Même Content-Length mesure la différence transmise, non la longueur du document reconstruit. Confondre ces dimensions convertirait l'optimisation en apparente troncature.

L'ordre des transformations fait partie de la recette

Le RFC place les opérations dans une chaîne: choix de la ressource et de la variante, codage de contenu, attribution de l'ETag d'instance, manipulation telle que delta ou plage, puis codage de transfert.

Changer l'ordre change potentiellement les octets. Delta puis plage n'est pas nécessairement plage puis delta. Une compression appliquée comme codage de contenu participe à la définition de l'instance; appliquée comme manipulation ultérieure, elle appartient à une autre étape.

A-IM et IM rendent l'ordre des manipulations visible. Un cache ne peut conserver seulement un ensemble de noms et les réordonner au moment de rejouer la réponse. La séquence et les paramètres appartiennent à la provenance.

L'économie d'octets n'est fiable que si la recette qui redonne leur sens reste attachée au message.

Le code 226 devait arrêter les caches ignorants

Les auteurs ne souhaitaient pas créer un nouveau statut. Le parc installé les y a poussés.

HTTP demande généralement d'ignorer les champs inconnus. Un ancien proxy pouvait donc ignorer IM, stocker le delta, puis le servir à un client comme s'il s'agissait du contenu complet. Le principe d'extensibilité aurait produit une corruption silencieuse.

Un statut 226 inconnu formait une barrière plus visible. Les observations rapportées par le RFC suggéraient que les anciens proxies transmettaient les statuts inconnus sans tenter de les mettre en cache. Ils pouvaient acheminer le message sans prétendre le comprendre.

Le document avertit même que Vary: If-None-Match, A-IM ne suffit pas dans au moins un scénario de validation erronée. La différence sémantique devait atteindre un endroit que le comportement ancien ne réduisait pas à un 200 ordinaire.

IM décrit la recette, 226 annonce la manipulation

Une réponse delta doit porter 226 et un champ IM indiquant au moins le codage delta. La requête doit avoir offert la manipulation dans A-IM et une base dans If-None-Match.

Le statut indique que GET a été satisfait par le résultat d'une ou plusieurs manipulations de l'instance courante. Selon la recette, l'instance complète n'existe chez le destinataire qu'après combinaison avec une réponse antérieure ou future.

226 ne signifie donc pas uniquement « delta ». Le cadre peut composer plusieurs manipulations, notamment une sélection de plage. IM énumère la chaîne; 226 interdit de supposer que le corps est directement l'instance complète.

Le destinataire doit lire les champs structurés, non interpréter librement la courte phrase « IM Used ».

Un cache compétent pouvait reconstruire

Interdire tout stockage aurait sacrifié une partie du gain. Le RFC distingue donc le cache ignorant du cache capable de respecter l'ensemble du contrat.

Un cache compétent peut décoder toutes les manipulations, reconstruire l'instance courante et la conserver comme réponse 200. Il peut laisser seulement la sélection de plage et obtenir une entrée 206 conforme. Il peut enfin garder la forme 226 sous des contraintes spécifiques.

La réutilisation brute exige que la requête suivante accepte les mêmes manipulations, paramètres et ordre, ainsi que les règles de fraîcheur et d'identité. Un delta stocké n'est jamais une variante autonome disponible pour n'importe quel GET.

La directive Cache-Control im fournissait une frontière de capacité: no-store arrêtait les caches ordinaires, tandis qu'une implémentation comprenant 226, A-IM et IM pouvait suivre les instructions réservées à ce savoir-faire.

Garder le passé coûte de l'espace et du calcul

La différence n'existe que si une base utile demeure disponible. Le client peut conserver plusieurs anciennes instances et proposer plusieurs ETag. Le serveur qui possède encore certaines versions choisit celle qui produit une différence intéressante et la nomme avec Delta-Base.

Mais la mémoire des caches est finie, l'historique du serveur aussi, et comparer plusieurs bases consomme CPU, mémoire et accès disque. Un indice de conservation n'est pas une promesse perpétuelle.

L'optimisation déplace ainsi les incitations. Une ancienne copie peut être gardée non pour être affichée, mais pour servir de point de départ. L'origine peut pré-calculer ou conserver certains états, seulement si l'économie future justifie ce coût.

La faculté de revenir à 200 est donc une composante du contrôle opérationnel. Un delta plus gros, plus lent ou introuvable n'est pas un échec du protocole; c'est une optimisation refusée.

Les registres conservent aujourd'hui la grammaire

Le registre IANA des statuts HTTP associe toujours 226 IM Used au RFC 3229. Le registre IANA des champs HTTP classe A-IM, Delta-Base et IM comme champs permanents.

Cette présence ne prouve aucune diffusion actuelle. Elle protège une signification. Un destinataire peut retrouver la spécification, et un nouveau protocole ne doit pas réutiliser ces noms pour une autre idée d'incrément.

L'histoire à retenir n'est pas celle d'une victoire universelle du delta. C'est celle d'un mécanisme qui savait précisément quelles preuves exiger avant de transmettre moins.

La copie n'arrivait qu'à la fin du calcul

Avec 226, le message sur le fil et la représentation courante cessent d'être nécessairement le même objet. Le réseau transporte une transformation, mais ne prétend pas que cette transformation constitue seule le résultat.

Le client prouve sa base; le serveur la choisit et la nomme; IM fixe la suite des opérations; l'ETag de réponse nomme l'état reconstruit; le cache comprend toute la chaîne ou refuse d'en faire un document complet.

Sans cette filiation, le delta n'est pas une vérité économique. Ce sont de petits octets chargés d'une hypothèse invisible.

HTTP 226 a rendu l'hypothèse explicite. Le client ne recevait pas la nouvelle copie: il recevait un moyen vérifiable de la fabriquer à partir de celle qu'il pouvait prouver posséder.