Content-Location:

Syntaxe

Paramètres

Description

Ce champ d'entête permet d'indiquer un autre emplacement pour les données renvoyées. L'utilisation principale est d'indiquer un URL d'une ressource transmise à la suite de la négociation de contenu.

Remarques

• Le champ d'entête Content-Location: fait référence à un URI pouvant être utilisé comme identifiant pour une ressource spécifique correspondant à la représentation dans la charge utile de ce message. En d'autres termes, si l'on devait effectuer une requête GET sur cet URI au moment de la génération de ce message, alors une réponse 200 OK contiendrait la même représentation étant incluse comme charge utile dans ce message.
• La valeur Content-Location: ne remplace pas l'URI de requête effectif. Il s'agit de méta-données de représentation. Il a la même syntaxe et la même sémantique que le champ d'entête du même nom défini pour les parties du corps MIME. Cependant, son apparition dans un message HTTP a des implications particulières pour les destinataires HTTP.
• Si Content-Location: est inclus dans un message de réponse 2xx (réussi) et que sa valeur se réfère (après la conversion en forme absolue) à un URI étant le même que l'URI de requête effective, le destinataire peut considérer la charge utile comme une représentation actuelle de cette ressource à l'heure indiquée par la date d'origine du message. Pour une méthode GET ou HEAD, c'est la même chose que la sémantique par défaut quand aucun Content-Location: n'est pas fourni par le serveur. Pour une requête de changement d'état comme PUT ou POST, cette situation implique que la réponse du serveur contient la nouvelle représentation de cette ressource, la distinguant ainsi des représentations ne pouvant que rendre compte de l'action . Par conséquent, il permet aux applications de création de mettre à jour leurs copies locales sans avoir besoin d'une requête GET ultérieure.
• Si Content-Location: est inclus dans un message de réponse 2xx (réussi) et que sa valeur de champ fait référence à un URI différant de l'URI de requête effective, le serveur d'origine prétend que l'URI est un identifiant pour une ressource différente correspondant à la ressource jointe représentation. Une telle revendication ne peut être approuvée que si les deux identificateurs partagent le même propriétaire de ressource, cette situation ne pouvant pas être déterminé par programme via HTTP.
• Pour une réponse à une requête GET ou HEAD, cette situation indique que l'URI de la requête effective fait référence à une ressource faisant l'objet d'une négociation de contenu et que la valeur de champ Content-Location: est un identificateur plus spécifique pour la représentation sélectionnée.
• Pour une réponse 201 Created à une méthode de changement d'état, une valeur de champ Content-Location: identique à la valeur de champ Location: indique que cette charge utile est une représentation actuelle de la ressource nouvellement créée.
• Sinon, un tel Content-Location: indique que cette charge utile est une représentation faisant rapport sur l'état de l'action demandée et que le même rapport est disponible (pour un accès futur avec GET) à l'URI spécifié. Par exemple, une transaction d'achat effectuée via une requête POST peut inclure un document de réception comme charge utile de la réponse 200 OK; la valeur de champ Content-Location: fournit un identifiant pour récupérer une copie de ce même reçu à l'avenir.
• Un agent utilisateur envoyant Content-Location: dans un message de requête indique que sa valeur fait référence à l'endroit où l'agent utilisateur a obtenu à l'origine le contenu de la représentation jointe (avant toute modification apportée par cet agent utilisateur). En d'autres termes, l'agent utilisateur fournit un lien de retour vers la source de la représentation d'origine.
• Un serveur d'origine recevant un champ Content-Location: dans un message de requête doit traiter les informations comme un contexte de requête transitoire plutôt que comme des méta-données à enregistrer textuellement dans le cadre de la représentation. Un serveur d'origine peut utiliser ce contexte pour guider le traitement de la demande ou l'enregistrer pour d'autres utilisations, comme dans les liens source ou les méta-données de version. Cependant, un serveur d'origine ne doit pas utiliser ces informations de contexte pour modifier la sémantique de la demande.
• Par exemple, si un client fait une requête PUT sur une ressource négociée et que le serveur d'origine accepte ce PUT (sans redirection), le nouvel état de cette ressource devrait être cohérent avec la représentation fournie dans ce PUT; l'emplacement de contenu ne peut pas être utilisé comme une forme d'identificateur de sélection de contenu inversé pour mettre à jour une seule des représentations négociées. Si l'agent utilisateur avait voulu cette dernière sémantique, il aurait appliqué le PUT directement à l'URI de Content-Location:.