Résumé

  • La RFC 2774 transformait GET en M-GET lorsqu’une extension était obligatoire : un serveur ignorant le mécanisme devait ainsi rejeter une méthode inconnue, au lieu d’exécuter la requête de base en oubliant sa condition essentielle.
  • Le destinataire capable répondait soit par 510 si la politique d’extension restait insatisfaite, soit par Ext ou C-Ext après compréhension et exécution ; l’expérience a ensuite été classée Historic et ses identifiants obsolètes.

Quand la compatibilité produit une réponse mensongère

Prenons une écriture HTTP dont la validité dépend d’une règle nouvelle. Un serveur récent lit cette règle et l’applique. Un serveur ancien ignore le champ inconnu, traite néanmoins l’écriture et renvoie un succès parfaitement plausible. Les deux échanges ont fonctionné du point de vue du réseau, mais un seul a respecté l’intention de l’émetteur.

Cette forme de compatibilité était la cible de la RFC 2774, publiée à titre expérimental en février 2000. Le problème ne consistait pas seulement à annoncer une capacité. Il fallait empêcher une opération de réussir lorsque le destinataire ne comprenait pas une sémantique déclarée indispensable.

La réponse choisie était volontairement visible. Une requête obligatoire ne portait plus la méthode habituelle : PUT devenait M-PUT, GET devenait M-GET. Un serveur non conforme ne pouvait pas reconnaître silencieusement la méthode de base. Son ignorance devait apparaître comme une incompatibilité, avant toute exécution accidentelle.

Un préfixe qui obligeait à prouver la compréhension

Le serveur connaissant le cadre ne se contentait pas d’enlever M-. Il devait d’abord identifier toutes les déclarations obligatoires, vérifier qu’il savait les appliquer au message, puis seulement exécuter leurs règles et celles de la méthode HTTP sous-jacente. Si une déclaration n’était pas prise en charge, il devait renvoyer 510 Not Extended.

La RFC interdisait explicitement de déclarer la requête satisfaite sans avoir compris et respecté toutes ses extensions obligatoires. Le préfixe faisait donc de l’incompatibilité une protection. Il refusait le compromis séduisant où un ancien composant conserve la disponibilité au prix du sens.

Une matrice pour dire qui devait agir

Le cadre séparait deux propriétés. Une extension pouvait être obligatoire ou facultative ; elle pouvait viser le destinataire final ou seulement le prochain maillon de la connexion. Quatre champs en résultaient : Man, Opt, C-Man et C-Opt.

Cette distinction distribuait l’autorité. Un proxy capable de lire une déclaration de bout en bout n’en devenait pas le destinataire. Une exigence de proche en proche, au contraire, devait être traitée sur la connexion concernée et protégée par le champ Connection en HTTP/1.1. Le message indiquait ainsi non seulement ce qu’il demandait, mais aussi à quel acteur la demande s’adressait.

Chaque extension possédait un identifiant globalement unique, généralement une URI. Une déclaration pouvait réserver un préfixe numérique, par exemple 16, afin que les champs 16-... appartiennent à cette instance. Ce petit espace de noms local au message évitait les collisions entre extensions et permettait plusieurs usages d’une même extension.

Le rôle exact de 510

Le statut 510 n’était pas une panne générale du serveur. La section 7 de la RFC 2774 le rattachait à une politique d’accès à la ressource que la requête étendue ne satisfaisait pas. La réponse devait indiquer les informations nécessaires à la formulation d’une demande acceptable.

Si le client pouvait ajouter les extensions manquantes, il avait la possibilité de modifier puis de répéter sa requête. Sinon, le corps de réponse devenait un diagnostic à présenter à l’utilisateur. Même une méthode M- dépourvue de toute déclaration obligatoire était incohérente et devait recevoir 510 : on ne pouvait pas exiger un traitement renforcé sans nommer l’exigence.

Le code matérialisait donc une frontière précise. Le serveur avait compris HTTP, la ressource existait peut-être, mais le contrat sémantique de cette opération n’était pas rempli.

Un succès avait aussi besoin d’un accusé de réception

Éviter le faux succès exigeait un signal positif. Le champ Ext indiquait que toutes les déclarations obligatoires de bout en bout avaient été exécutées. C-Ext attestait la même chose pour les déclarations de proche en proche. Ces champs ne transportaient aucune donnée métier ; ils étaient des accusés de compréhension et d’obéissance.

Ils ne certifiaient ni la qualité de l’extension, ni l’exactitude du résultat, ni la confiance à accorder au serveur. Leur portée était plus étroite et plus utile : distinguer un succès sous le contrat étendu d’une réponse ordinaire qui n’en disait rien.

Le coût des intermédiaires et des caches

Le document consacrait beaucoup d’efforts aux endroits où le sens pouvait se perdre. Une déclaration de bout en bout devait traverser des proxies non informés. Une déclaration de connexion devait s’arrêter au bon maillon. Un cache ne devait pas réutiliser une représentation calculée avec une extension pour une requête qui ne la portait pas.

La RFC imposait notamment Cache-Control: no-cache="Ext" après satisfaction d’une demande obligatoire de bout en bout. Pour les proxies HTTP/1.0, elle ajoutait une date Expires déjà passée. Lorsqu’une réponse variait selon un champ préfixé, Vary devait nommer ce champ et le champ de déclaration correspondant.

Chaque détail empêchait une perte de sémantique. Ensemble, ils montraient aussi l’ambition du dispositif : coordonner clients, origines, proxies, caches et versions d’HTTP dans un mécanisme générique. La sûreté demandée sur un seul message devenait une discipline pour tout le trajet.

De l’expérimental à l’historique

La note de l’IESG jointe dès l’origine est prudente. Le texte avait été proposé comme norme, mais les avis partagés et l’absence de consensus clair sur l’évolution d’HTTP ont conduit à son statut Experimental. L’IESG précisait que ce choix ne démontrait pas nécessairement des défauts techniques et déconseillait d’en faire un modèle universel.

En 2021, l’IETF a classé la RFC 2774 parmi les expériences HTTP devenues Historic. La justification officielle est limitée : les expériences étaient terminées et aucune utilisation largement répandue n’était attestée. Le registre IANA qualifie désormais 510 de Not Extended (OBSOLETED) et marque les six champs du cadre comme obsoleted.

Ces éléments ne permettent pas d’inventer une cause unique à l’absence d’adoption. Ils indiquent seulement que le mécanisme générique n’appartient plus au fonctionnement HTTP actuel.

La question qui a survécu au mécanisme

La RFC 9110 conserve des points d’extension permanents : méthodes, codes d’état, noms de champs, schémas d’authentification et directives de cache. Ils sont administrés par des registres explicites et des règles d’examen. HTTP a donc gardé la capacité d’évoluer sans conserver la matrice de déclarations et les méthodes M- de la RFC 2774.

L’expérience laisse une question de gouvernance. Comment un émetteur sait-il qu’une condition essentielle a été comprise, et non simplement traversée ? Il faut définir le nom, la portée, l’acteur responsable, l’échec visible et le cycle de vie d’une extension. Sans cela, la réponse la plus dangereuse reste celle qui dit « succès » alors que les deux côtés n’ont pas exécuté la même opération.

Sources