Obtenir des métadonnées de conteneur

L’opération Get Container Metadata renvoie toutes les métadonnées définies par l’utilisateur pour le conteneur.

Requête

La Get Container Metadata demande peut être formulée comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez myaccount par le nom de votre compte de stockage :

Method	URI de la requête	Version HTTP
`GET/HEAD`	`https://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata`	HTTP/1.1

Demande de service de stockage émulée

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

Method	URI de la requête	Version HTTP
`GET/HEAD`	`http://127.0.0.1:10000/devstoreaccount1/mycontainer?restype=container&comp=metadata`	HTTP/1.1

Pour plus d’informations, consultez Utiliser l’émulateur Azurite pour le développement stockage Azure local.

Paramètres d’URI

Les paramètres supplémentaires suivants peuvent être spécifiés sur l’URI de la requête :

Parameter	Description
`timeout`	Optional. Le paramètre `timeout` est exprimé en secondes. Pour plus d’informations, consultez Définir des délais d’expiration pour les opérations de Stockage Blob.

En-têtes de requête

Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs.

En-tête de requête	Description
`Authorization`	Required. Spécifie le schéma d’autorisation, le nom du compte et la signature. Pour plus d’informations, consultez Autoriser les demandes vers le stockage Azure.
`Date` ou `x-ms-date`	Required. Spécifie le temps universel coordonné (UTC) de la requête. Pour plus d’informations, consultez Autoriser les demandes vers le stockage Azure.
`x-ms-lease-id: <ID>`	Optionnel, version 2012-02-12 et ultérieure. Si elle est spécifiée, `Get Container Metadata` elle ne réussit que 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, le code d’erreur 412 (Échec de la précondition) est retourné.
`x-ms-version`	Obligatoire pour toutes les demandes autorisées, optionnelle pour les demandes anonymes. Spécifie la version de l’opération à utiliser pour cette requête. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure.
`x-ms-client-request-id`	Optional. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (KiB) 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 Monitor Stockage Blob Azure.

Corps de la demande

None.

Response

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

Code de statut

Une opération réussie retourne le code d’état 200 (OK).

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

En-têtes de réponse

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

Syntax	Description
`x-ms-meta-name:value`	Retourne une chaîne contenant une paire nom-valeur associée au conteneur comme métadonnées.
`ETag`	L’entité pour le conteneur. Si la version de la demande est 2011-08-18 ou une version ultérieure, la valeur ETag est placée entre guillemets.
`Last-Modified`	Renvoie la date et l’heure de la dernière modification du conteneur. Le format de date suit la RFC 1123. Pour plus d’informations, voir Représentation des valeurs de Date-Time dans les en-têtes. Toute opération qui modifie le conteneur, ses propriétés ou ses métadonnées met à jour l’heure de la dernière modification. Les opérations sur les blobs n’affectent pas le dernier temps modifié du conteneur.
`x-ms-request-id`	Cet en-tête identifie de manière unique la demande qui a été effectuée et peut être utilisé pour résoudre les problèmes de la demande. Pour plus d’informations, voir Dépannage des opérations API.
`x-ms-version`	Version du service utilisée pour exécuter la requête. Cet en-tête est renvoyé pour les demandes effectuées sur la version 2009-09-19 et les versions ultérieures. L’en-tête est également retourné pour les requêtes anonymes sans version spécifiée si le conteneur a été marqué pour un accès public en utilisant la version du service 2009-09-19.
`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.
`x-ms-client-request-id`	Peut être utilisé pour résoudre les problèmes liés aux demandes et aux 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 requête, il n’est pas présent dans la réponse.

Corps de réponse

None.

Exemple de réponse

  
Response Status:  
HTTP/1.1 200 OK  
  
Response headers:  
Transfer-Encoding: chunked  
x-ms-meta-AppName: StorageSample  
Date: Sun, 25 Sep 2011 23:43:08 GMT  
ETag: "0x8CAFB82EFF70C46"  
Last-Modified: Sun, 25 Sep 2011 19:42:18 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

L’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 de Get Container Metadata comme décrit ci-dessous.

Important

Microsoft recommande d’utiliser l’ID Microsoft Entra avec des identités managées pour autoriser les demandes adressées au stockage Azure. Microsoft Entra ID offre une sécurité et une facilité d’utilisation supérieures par rapport à l’autorisation de clé partagée.

Le Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour autoriser les requêtes d’accès aux données d’objets blob. Avec l’ID Microsoft Entra, 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 demande auprès du service Blob.

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

Permissions

Voici l’action RBAC nécessaire pour un utilisateur, un groupe, une identité managée ou un principal de service Microsoft Entra pour appeler l’opération de Get Container Metadata et le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure :Microsoft. Storage/storageAccounts/blobServices/conteneurs/lecture
rôle intégré moins privilégié :lecteur de données Blob du 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.

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 avez 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 a besoin pour ces ressources et la durée pendant laquelle la SAP est valide.

L’opération Get Container Metadata prend en charge l’autorisation via un compte SAS uniquement. Le SAS de service et le SAS de délégation utilisateur ne sont pas pris en charge pour cette opération.

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

Compte SAS

Un SAS de compte est sécurisé à l’aide de la clé du compte de stockage. Un SAS de compte délègue l’accès aux ressources à 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 :

Operation	Service signé	Type de ressource signé	Autorisation signée
Obtenir des métadonnées de conteneur	Blob (b)	Conteneur (c)	Lire (r)

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

L’opération de Get Container Metadata prend en charge d’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 de refuser l’autorisation de clé partagée pour le compte de stockage si possible. Pour plus d’informations, consultez Empêcher l’autorisation avec une clé partagée.

Remarques

Cette opération ne renvoie que les métadonnées définies par l’utilisateur sur le conteneur. Pour retourner aussi les propriétés système, appelez Obtenir des propriétés du conteneur.

Billing

Les demandes de tarification peuvent provenir de clients qui utilisent des API Stockage Blob, directement via l’API REST Stockage Blob ou à 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 en écriture. Le tableau suivant montre la catégorie de facturation pour les requêtes Get Container Metadata en fonction du type de compte de stockage :

Operation	Type de compte de stockage	Catégorie de facturation
Obtenir des métadonnées de conteneur	Blob de blocs Premium Standard à usage général v2	Autres opérations
Obtenir des métadonnées de conteneur	Standard v1 à usage général	Opérations de lecture

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

Voir également :

Opérations sur les conteneurs

Dernière mise à jour : 2026-11-05