Résumé

  • Content-Location identifie la ressource précise correspondant à la représentation contenue dans le message. Son interprétation dépend de la méthode, du statut et de l’égalité avec l’URI cible ; il ne remplace jamais cette cible.
  • La métadonnée peut aider à mettre à jour une copie locale, à nommer une variante négociée ou à retrouver un rapport d’opération. Elle ne suffit pas à rediriger, canoniser, prouver un propriétaire commun ou autoriser une lecture ou une écriture ultérieure.

Un client envoie une requête POST à un service d’achat. La réponse 200 contient un reçu ainsi que Content-Location: /reçus/47. Trois adresses peuvent désormais coexister : celle du service ayant reçu l’opération, celle d’un éventuel objet créé et celle du document qui rapporte le résultat.

Les réduire à une seule « bonne URL » serait commode, mais faux. Le champ dit à quelle ressource correspond la représentation jointe. Il ne déplace pas la requête qui vient d’avoir lieu et ne donne pas au client la consigne de recommencer ailleurs.

Cette modestie est le cœur de la section 8.7 de RFC 9110. Elle montre comment un protocole peut enrichir l’identité d’un document sans créer au passage un pouvoir de routage, de propriété ou de mutation.

La cible conserve l’opération

L’URI cible fait partie de la sémantique de la requête. Elle désigne la ressource à laquelle la méthode s’applique et participe au routage du message. Lorsque le serveur répond, un champ peut fournir une information supplémentaire sur le contenu retourné ; il ne réécrit pas rétroactivement la ligne de requête.

Content-Location référence une URI absolue ou partielle. Cette URI peut identifier la ressource précise correspondant à la représentation présente dans le contenu du message. Le standard explique l’idée par une expérience temporelle : à l’instant de la génération du message, un GET sur cette URI aurait renvoyé la même représentation dans une réponse 200.

Une référence partielle se résout relativement à l’URI cible, conformément aux règles ordinaires des URI. Une fois la forme absolue obtenue, le destinataire peut la comparer avec la cible. Pourtant, même lorsqu’elles diffèrent, le standard tranche : la valeur n’est pas un remplacement de l’URI cible. C’est une métadonnée de représentation.

La ressemblance graphique entre deux URI favorise les confusions. Les logiciels savent les normaliser, les ouvrir ou les enregistrer comme clés. Ils sont alors tentés d’utiliser le dernier champ observé comme destination de toutes les opérations futures. Mais « ressource visée par la méthode » et « ressource correspondant au document retourné » répondent à deux questions différentes.

Le champ Location en pose une troisième. Selon le statut, il peut identifier une ressource nouvellement créée ou donner une référence de redirection. Une même réponse peut contenir Location et Content-Location, car l’endroit défini par le statut et le document contenu dans la réponse peuvent avoir des fonctions distinctes.

L’égalité précise la nature du corps

Dans une réponse 2xx, si la forme absolue de Content-Location est identique à l’URI cible, le destinataire peut considérer le contenu comme une représentation actuelle de cette ressource à la date d’origine du message.

Pour GET et HEAD, cela correspond au comportement ordinaire. Même sans le champ, une réponse GET réussie est comprise comme une représentation de la cible sélectionnée. La présence de Content-Location n’accorde donc pas un pouvoir nouveau.

Après PUT ou POST, l’information devient plus discriminante. Imaginons qu’un outil envoie un nouveau document par PUT, puis reçoive un 200 dont Content-Location est la cible du PUT. Le corps représente le nouvel état de cette ressource ; ce n’est pas seulement un message disant « opération réussie ». L’outil d’édition peut actualiser sa copie locale sans effectuer immédiatement un autre GET.

Le gain porte sur la connaissance du résultat, non sur le droit de recommencer. L’autorisation du PUT a été évaluée pour la requête déjà envoyée. La métadonnée ne prolonge pas cette autorisation, ne garantit pas que l’état restera stable et ne synchronise pas automatiquement les autres caches.

Le repère temporel évite une autre exagération. L’équivalence est décrite au moment où le message est produit. Un GET ultérieur peut rencontrer une nouvelle version, une sélection différente, une politique d’accès modifiée ou une ressource disparue. Le champ ne promet pas des octets immuables pour toujours.

Une valeur différente ouvre plusieurs cas, pas une règle générale

Lorsque Content-Location diffère de la cible dans une réponse réussie, il faut lire la méthode et le statut avant d’agir.

Après GET ou HEAD, la différence peut indiquer une négociation de contenu. L’URI cible représente une ressource offrant plusieurs variantes ; le champ fournit un identifiant plus précis pour la variante sélectionnée. Un rapport général peut, par exemple, renvoyer une représentation française disposant de sa propre URI.

Cette précision n’abolit pas l’adresse négociée. La cible large reste utile pour choisir une langue ou un format en fonction du prochain lecteur. L’URI particulière identifie ce qui a été choisi cette fois. Déclarer l’une « canonique » au détriment de l’autre est une décision supplémentaire qui requiert un mécanisme et une politique explicites.

Après une méthode modifiant l’état, la réponse 201 crée un autre cas. Lorsque Content-Location et Location sont identiques, le contenu est une représentation actuelle de la nouvelle ressource. Location remplit la fonction liée à la création ; Content-Location décrit le corps. Le fait que leurs valeurs coïncident ne fusionne pas leurs sémantiques.

Dans les autres réponses 2xx à une opération, une valeur différente peut identifier un rapport d’état disponible plus tard par GET. RFC 9110 prend l’exemple d’un achat : POST vise le service transactionnel, tandis que le corps et son Content-Location correspondent à un reçu consultable ultérieurement.

Un journal sérieux conserve donc séparément la cible de l’action, la ressource créée et le rapport. S’il remplace ces trois identités par une URL canonique, les opérations suivantes deviennent ambiguës. Un GET lit-il la transaction, l’objet ou son reçu ? Un PUT cherche-t-il à corriger l’objet acheté ou le document qui le raconte ?

La propriété commune n’est pas déductible du seul HTTP

Quand les URI diffèrent, le serveur d’origine affirme que l’autre URI identifie une ressource correspondant à la représentation jointe. RFC 9110 ajoute immédiatement une réserve : cette affirmation ne peut être jugée digne de confiance que si les deux identifiants partagent le même propriétaire de ressource, relation que HTTP ne sait pas déterminer automatiquement.

Comparer les origines fournit un contrôle utile, mais pas un registre de propriété. Un hébergeur mutualisé peut servir plusieurs organisations sous une même origine. Inversement, une seule organisation peut exploiter légitimement plusieurs domaines. Les mandataires et plateformes éditoriales séparent encore davantage la garde technique de l’autorité sur le contenu.

Le client à fort enjeu a donc besoin d’une règle propre à l’application : relation de compte authentifiée, espace de noms examiné, manifeste signé dans une portée précise ou confirmation humaine. La qualité de preuve exigée dépend de l’effet envisagé.

Une signature de message HTTP ne transforme pas cette question en certitude universelle. RFC 9421 permet de protéger des composants choisis et de les associer à un signataire selon un profil d’application. Le texte souligne qu’il ne constitue qu’une partie du système de sécurité. Un Content-Location intact prouve l’intégrité des données couvertes ; il reste à savoir si le signataire avait qualité pour affirmer une propriété commune et si une méthode future est autorisée.

L’intégrité d’une affirmation n’équivaut pas à la légitimité de l’affirmation.

Dans une requête, le champ reste un contexte transitoire

Un agent utilisateur peut envoyer Content-Location avec une représentation. Il indique alors l’endroit où il avait obtenu le contenu d’origine avant de le modifier. Le champ fonctionne comme un lien de retour vers la source.

Le serveur doit traiter cette donnée comme un contexte transitoire de la requête, et non comme une métadonnée à recopier telle quelle dans la représentation enregistrée. Il peut s’en servir pour son traitement ou conserver une référence de source ou de version appropriée. Il ne doit pas l’utiliser pour changer la sémantique de la requête.

Le cas d’un PUT sur une ressource négociée rend la règle tangible. Le client a édité une variante et la cite dans Content-Location, mais adresse son PUT à la ressource négociée. Si le serveur accepte sans redirection, le nouvel état de la cible doit être cohérent avec la représentation fournie. Le champ ne permet pas de transformer l’opération en mise à jour exclusive de la variante citée.

Pour demander cette opération plus étroite, le client doit envoyer le PUT directement à l’URI de la variante. La cible, les contrôles d’accès et le journal de l’opération décrivent alors la même ressource.

Sans cette limite, le champ deviendrait un moyen de glisser une seconde cible derrière la première. Une passerelle pourrait autoriser l’URI visible, tandis que l’application modifierait celle du champ ; les preuves ne diraient plus sur quoi portait la méthode.

L’invalidation du cache est bornée à son propre rôle

RFC 9111 attribue une conséquence particulière à Content-Location. Après une réponse sans erreur à une méthode non sûre, un cache invalide les réponses enregistrées pour l’URI cible. Les URI présentes dans Location et Content-Location peuvent également être candidates.

Cette possibilité est limitée par l’origine. Le cache ne doit pas déclencher cette invalidation si l’origine de l’URI candidate diffère de celle de la cible. Le garde-fou évite qu’une écriture sur un site permette d’épuiser ou de perturber les entrées d’un autre site.

Invalider signifie retirer une réponse stockée ou la marquer comme nécessitant une validation avant réutilisation. Ce n’est pas écrire sur la ressource d’origine, supprimer un document mondialement ni rediriger le lecteur. Seuls les caches traversés par la requête peuvent agir ; le standard précise que l’invalidation globale n’est pas garantie.

Le champ produit donc un effet défini dans un sous-système précis. Le cache protège la cohérence de ses propres copies. Cette fonction n’accorde ni navigation automatique à l’agent utilisateur, ni droit de PUT à l’éditeur, ni règle canonique au moteur d’indexation.

La bonne discipline consiste à nommer le consommateur de chaque effet. Une implication de cache ne doit pas devenir par analogie une implication de routage.

L’identité d’une variante n’est pas sa couronne canonique

La négociation de contenu permet à une ressource d’avoir plusieurs représentations selon la langue, le format ou l’encodage. Content-Location peut fournir un identifiant spécifique pour celle qui voyage dans ce message.

Cette information est précieuse. Une application peut enregistrer la variante exacte plutôt que seulement le point de négociation. Elle peut reconstruire la provenance d’une copie et tenter de retrouver le même rapport. Mais la spécificité ne crée pas une hiérarchie universelle.

Web Linking offre un mécanisme distinct pour déclarer des relations typées entre ressources. Une relation canonique, une variante ou une description doit employer les conventions prévues pour cette relation. Faire de Content-Location un paquet implicite de toutes ces déclarations rendrait chaque client dépendant d’une supposition privée.

Le risque se manifeste dans les outils de publication. Un robot reçoit une URI spécifique, la place dans l’index canonique, réachemine ensuite les éditions et finit par signer les requêtes vers cette adresse. Chaque saut paraît petit ; aucun n’était promis par la métadonnée initiale.

Le modèle de données doit conserver séparément cible, statut, Location, Content-Location, dimensions de négociation, origine authentifiée et heure. La décision suivante indique lequel de ces éléments elle utilise.

Un vocabulaire commun n’exige pas une autorité centrale

Le registre IANA des noms de champs HTTP classe Content-Location comme permanent et renvoie à RFC 9110. Cette inscription donne aux applications un nom et une sémantique communs. Elle ne constitue pas un cadastre mondial des propriétaires d’URI.

L’architecture rejoint la séquence de Lu Heng. La spécification initiale minimale contient la syntaxe, la résolution des URI et une matrice fondée sur la méthode, le statut et l’égalité. Les décisions futures restent localisées. L’origine choisit l’identifiant qu’elle peut affirmer. Le client évalue la propriété commune. Le cache applique sa borne d’origine. L’outil d’édition décide si le corps met à jour sa copie.

L’adoption demeure volontaire et informée : un destinataire peut utiliser le champ pour un bénéfice précis sans accepter toutes les inférences imaginables. Aucun service central n’a à approuver chaque variante, chaque reçu ou chaque invalidation locale.

Le résultat n’est pas une fragmentation du sens. Le sens commun est strict ; les conséquences restent proportionnées à l’autorité de chaque participant.

Produire un reçu de représentation

Une implémentation robuste ne remplace jamais une URI par une autre sans trace. Elle consigne la méthode, la cible, le statut, la date du message, le Content-Location résolu, l’éventuel Location, les dimensions négociées, le pair authentifié et l’empreinte de la représentation.

Elle choisit ensuite une interprétation dans la matrice : représentation actuelle de la cible, variante sélectionnée, représentation de la ressource créée ou rapport d’état. Elle n’emploie pas une règle générique « suivre ce champ ».

Chaque effet forme une ligne distincte : mise à jour d’une copie locale, planification d’un GET, invalidation d’une entrée de cache ou proposition d’une relation canonique. Une signature précise les composants couverts et le profil qui a accepté le signataire.

Enfin, la preuve peut être corrigée. La ressource change, la variante disparaît, le propriétaire retire sa délégation ou le serveur corrige un champ erroné. Le message initial reste une observation historique, pas une instruction permanente.

Content-Location répond à une question étroite et utile : à quelle ressource correspond cette représentation ? Il ne décide pas où le client doit aller, quelle URI remplace les autres, qui possède les deux ressources ou quelle méthode est permise. Sa valeur durable vient de ce refus de gouverner au-delà de sa portée.

Sources