Set Container Metadata

L'opération Set Container Metadata définit une ou plusieurs paires nom-valeur définies par l'utilisateur pour le conteneur spécifié.

Requête

La demande Set Container Metadata peut être construite comme indiqué ci-dessous. Nous vous recommandons d’utiliser HTTPS. Remplacez moncompte par le nom de votre compte de stockage :

Méthode	URI de demande	Version HTTP
PUT	https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata	HTTP/1.1

Demande de service de stockage émulée

Lorsque vous effectuez une requête auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port du service Blob comme 127.0.0.1:10000, suivi du nom du compte de stockage émulé :

Méthode	URI de demande	Version HTTP
PUT	http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=metadata	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite à des fins de développement local pour Stockage Azure.

Paramètres URI

Vous pouvez spécifier les paramètres supplémentaires suivants dans l’URI de requête :

Paramètre	Description
timeout	facultatif. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’attente pour les opérations de service Blob.

En-têtes de requête

Les en-têtes de requête obligatoires et facultatifs sont décrits dans le tableau suivant :

En-tête de requête	Description
Authorization	Obligatoire. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
Date ou x-ms-date	Obligatoire. Spécifie la date/heure en temps universel coordonné (UTC) pour la requête. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure.
x-ms-version	Obligatoire pour toutes les demandes autorisées. Spécifie la version de l'opération à utiliser pour cette demande. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
x-ms-lease-id: <ID>	Facultatif, version 2012-02-12 et ultérieure. S’il est spécifié, Set Container Metadata réussit uniquement si le bail du conteneur est actif et correspond à cet ID. S’il n’y a pas de bail actif ou si l’ID ne correspond pas, 412 (Échec de la condition préalable) est retourné.
x-ms-meta-name:value	facultatif. Une paire nom-valeur à associer au conteneur en tant que métadonnées. Chaque appel à cette opération remplace toutes les métadonnées existantes attachées au conteneur. Pour supprimer toutes les métadonnées du conteneur, appelez cette opération sans en-tête de métadonnées. Remarque : À partir de la version 2009-09-19, les noms de métadonnées doivent respecter les règles de nommage des identificateurs C#.
x-ms-client-request-id	facultatif. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (Kio) enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes reçues par le serveur. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

Cette opération prend uniquement en charge l'utilisation d'en-têtes conditionnels pour définir les métadonnées du conteneur uniquement si une condition spécifique est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de service Blob.

Corps de la demande

Aucun.

Exemple de requête

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata HTTP/1.1  
  
Request Headers:  
x-ms-version: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 22:50:32 GMT  
x-ms-meta-Category: Images  
Authorization: SharedKey myaccount:Z5043vY9MesKNh0PNtksNc9nbXSSqGHueE00JdjidOQ=  

response

La réponse inclut un code d'état HTTP et un ensemble d'en-têtes de réponse.

Code d’état

Une opération réussie envoie le code d'état 200 (OK).

Pour plus d’informations sur les codes status, consultez Codes d’état et d’erreur.

En-têtes de réponse

La réponse de l'opération inclut les en-têtes suivants. La réponse peut aussi inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse	Description
ETag	L'ETag du conteneur. Si la version de la demande est 2011-08-18 et versions ultérieures, la valeur ETag est placée entre guillemets.
Last-Modified	Retourne la date et l’heure de la dernière modification du conteneur. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représenter les valeurs de date/heure dans les en-têtes. Toute opération qui modifie le conteneur ou ses propriétés ou métadonnées met à jour l'heure de la dernière modification, notamment la définition des autorisations du conteneur. Les opérations sur les objets blob n’affectent pas l’heure de dernière modification du conteneur.
ms-request-id	Identifie de manière unique la demande qui a été effectuée et peut être utilisée pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
x-ms-version	Indique la version du service Blob utilisée pour exécuter la demande. Cet en-tête est retourné pour les demandes effectuées sur la version 2009-09-19 et ultérieure.
Date	Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
Access-Control-Allow-Origin	Retourné si la requête inclut un Origin en-tête et le partage de ressources entre origines (CORS) est activé avec une règle correspondante. Cet en-tête retourne la valeur de l’en-tête de la demande d’origine s’il existe une correspondance.
Access-Control-Expose-Headers	Retourné si la demande inclut un en-tête Origin et le partage de ressources cross-origine (CORS) est activé avec une règle de correspondance. Retourne la liste des en-têtes de réponse qui doivent être exposés au client ou à l'émetteur de la demande.
Access-Control-Allow-Credentials	Retourné si la requête inclut un Origin en-tête et que CORS est activé avec une règle correspondante qui n’autorise pas toutes les origines. Cet en-tête a la valeur true.
x-ms-client-request-id	Cet en-tête peut être utilisé pour résoudre les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id s’il est présent dans la requête et que la valeur ne contient pas plus de 1 024 caractères ASCII visibles. Si l’en-tête x-ms-client-request-id n’est pas présent dans la demande, il ne sera pas présent dans la réponse.

Response body

Aucun.

Autorisation

Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans Stockage Azure. Vous pouvez autoriser l’opération Set Container Metadata comme décrit ci-dessous.

Microsoft Entra ID

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les demandes de données blob. Avec Microsoft Entra ID, vous pouvez utiliser le contrôle d’accès en fonction du rôle Azure (Azure RBAC) pour accorder des autorisations à un principal de sécurité. Le principal de sécurité peut être un utilisateur, un groupe, un principal de service d’application ou une identité managée Azure. Le principal de sécurité est authentifié par Microsoft Entra ID pour retourner un jeton OAuth 2.0. Le jeton peut ensuite être utilisé pour autoriser une requête auprès du service BLOB.

Pour en savoir plus sur l’autorisation à l’aide de Microsoft Entra ID, consultez Autoriser l’accès aux objets blob à l’aide de Microsoft Entra ID.

Autorisations

Vous trouverez ci-dessous l’action RBAC nécessaire pour qu’un utilisateur, un groupe ou un principal de service Microsoft Entra appelle l’opérationSet Container Metadata, ainsi que le rôle RBAC intégré Azure le moins privilégié qui inclut cette action :

• Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/write
• Rôle intégré avec privilèges minimum :Contributeur aux données Blob de stockage

Pour en savoir plus sur l’attribution de rôles à l’aide d’Azure RBAC, consultez Attribuer un rôle Azure pour accéder aux données blob.

Signatures d’accès partagé (SAP)

Une signature d’accès partagé (SAP) fournit un accès délégué sécurisé aux ressources d’un compte de stockage. Avec une SAP, vous disposez d’un contrôle granulaire sur la façon dont un client peut accéder aux données. Vous pouvez spécifier la ressource à laquelle le client peut accéder, les autorisations dont il dispose sur ces ressources et la durée de validité de la signature d’accès partagé.

L’opération Set Container Metadata prend en charge l’autorisation à l’aide d’une SAP de compte.

Lorsque l’accès à la clé partagée n’est pas autorisé pour le compte de stockage, un jeton SAP de compte n’est pas autorisé sur une demande adressée au stockage Blob. Pour en savoir plus, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de compte

Une SAP de compte est sécurisée à l’aide de la clé de compte de stockage. Une SAP de compte délègue l’accès aux ressources d’un ou plusieurs des services de stockage. Toutes les opérations disponibles via une SAP de service ou de délégation d’utilisateur sont également disponibles via une SAP de compte.

Le tableau suivant indique le type de ressource signé et les autorisations signées à spécifier lors de la délégation de l’accès :

Opération	Service signé	Type de ressource signé	Autorisation signée
Set Container Metadata	Blob (b)	Service(s)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Créer une SAP de compte.

Clé partagée

L’opération Set Container Metadata prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée pour la plupart des scénarios, car elle est moins sécurisée.

Microsoft recommande d’interdire l’autorisation de clé partagée pour le compte de stockage lorsque cela est possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

L’appel de l’opération Set Container Metadata remplace toutes les métadonnées existantes associées au conteneur. Il n'est pas possible de modifier une paire nom-valeur individuelle.

Vous pouvez également définir des métadonnées pour un conteneur lors de sa création.

L’appel Set Container Metadata met à jour l’ETag et Last-Modified-Time les propriétés du conteneur. Si la demande a été effectuée à l’aide de la version 2011-08-18, l’ETag mis à jour est placé entre guillemets.

Facturation

Les demandes de tarification peuvent provenir de clients qui utilisent les API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à partir d’une bibliothèque cliente stockage Azure. Ces demandes accumulent des frais par transaction. Le type de transaction affecte la façon dont le compte est facturé. Par exemple, les transactions de lecture s’accumulent dans une catégorie de facturation différente de celle des transactions d’écriture. Le tableau suivant montre la catégorie de facturation pour Set Container Metadata les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Set Container Metadata	Objet blob de blocs Premium Usage général v2 Standard	Autres opérations
Set Container Metadata	Usage général v1 standard	Opérations d’écriture

Pour en savoir plus sur la tarification de la catégorie de facturation spécifiée, consultez tarification Stockage Blob Azure.

Voir aussi

Codes d’état et d’erreur
Codes d’erreur du service Blob
Définir et récupérer des propriétés et des métadonnées pour les ressources de Stockage Blob