Put Block List

Article
02/07/2024

L'opération Put Block List écrit un objet blob en spécifiant la liste des ID de bloc qui le composent. Pour être écrit dans le cadre d’un objet blob, un bloc doit avoir été écrit avec succès sur le serveur lors d’une opération Put Block antérieure.

Vous pouvez appeler Put Block List pour mettre à jour un objet blob en chargeant uniquement les blocs qui ont changé, puis en validant ensemble les blocs nouveaux et existants. Pour ce faire, spécifiez s’il faut valider un bloc à partir de la liste de blocs validée ou de la liste de blocs non validée, ou pour valider la dernière version chargée du bloc, quelle que soit la liste à laquelle il appartient.

Requête

Vous pouvez construire la Put Block List requête comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez moncompte par le nom de votre compte de stockage :

URI de demande de méthode PUT	Version HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist`	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é :

URI de demande de méthode PUT	Version HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist`	HTTP/1.1

L’émulateur de stockage prend en charge des tailles d’objet blob allant jusqu’à 2 gibibytes (Gio) uniquement.

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.
`Content-Length`	Obligatoire. Longueur du contenu de la demande, en octets. Cet en-tête fait référence à la longueur du contenu de la liste des blocs, et non à l’objet blob lui-même.
`Content-MD5`	facultatif. Un hachage MD5 du contenu de la demande. Ce hachage est utilisé pour vérifier l'intégrité du contenu de la demande pendant le transport. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte). Cet en-tête est associé au contenu de la requête, et non au contenu de l’objet blob lui-même.
`x-ms-content-crc64`	facultatif. Hachage CRC64 du contenu de la demande. Ce hachage est utilisé pour vérifier l'intégrité du contenu de la demande pendant le transport. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte). Cet en-tête est associé au contenu de la requête, et non au contenu de l’objet blob lui-même. Si les en-têtes Content-MD5 et x-ms-content-crc64 sont présents, la demande échoue avec un 400 (requête incorrecte). Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
`x-ms-blob-cache-control`	facultatif. Définit le contrôle du cache de l'objet blob. Si cette propriété est spécifiée, elle est stockée avec l’objet blob et retournée avec une demande de lecture. Si la propriété n’est pas spécifiée avec la demande, elle est effacée pour l’objet blob si la demande réussit.
`x-ms-blob-content-type`	facultatif. Définit le type de contenu de l'objet blob. Si elle est spécifiée, cette propriété est stockée avec l’objet blob et retournée avec une demande de lecture. Si le type de contenu n’est pas spécifié, il est défini sur le type par défaut, qui est `application/octet-stream`.
`x-ms-blob-content-encoding`	facultatif. Définit l'encodage du contenu de l'objet blob. Si elle est spécifiée, cette propriété est stockée avec l’objet blob et retournée avec une demande de lecture. Si la propriété n’est pas spécifiée avec la demande, elle est effacée pour l’objet blob si la demande réussit.
`x-ms-blob-content-language`	facultatif. Définit la langue de contenu de l’objet blob. Si elle est spécifiée, cette propriété est stockée avec l’objet blob et retournée avec une demande de lecture. Si la propriété n’est pas spécifiée avec la demande, elle est effacée pour l’objet blob si la demande réussit.
`x-ms-blob-content-md5`	facultatif. Un hachage MD5 du contenu de l'objet blob. Ce hachage n’est pas validé, car les hachages des blocs individuels ont été validés lorsque chacun d’eux a été chargé. L’opération Get Blob retourne la valeur de cet en-tête dans l’en-tête de réponse Content-MD5. Si cette propriété n’est pas spécifiée avec la demande, elle est effacée pour l’objet blob si la demande réussit.
`x-ms-meta-name:value`	facultatif. Paires nom-valeur définies par l’utilisateur qui sont associées à l’objet blob. À 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-encryption-scope`	facultatif. Indique l’étendue de chiffrement à utiliser pour chiffrer l’objet blob. Cette valeur doit correspondre à l’étendue de chiffrement utilisée pour chiffrer tous les blocs en cours de validation. Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
`x-ms-encryption-context`	facultatif. La valeur par défaut est « Empty ». Si la valeur est définie, les métadonnées du système d’objets blob seront définies. Longueur maximale 1024. Valide uniquement lorsque l’espace de noms hiérarchique est activé pour le compte. Cet en-tête est pris en charge dans les versions 2021-08-06 et ultérieures.
`x-ms-tags`	facultatif. Définit les balises encodées de chaîne de requête spécifiées sur l’objet blob. Pour plus d’informations, consultez la section Remarques . Pris en charge dans les versions 2019-12-12 et ultérieures.
`x-ms-lease-id:<ID>`	Obligatoire si l'objet blob a un bail actif. Pour effectuer cette opération sur un objet blob avec un bail actif, spécifiez l'ID de bail valide pour cet en-tête.
`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 d’analyse lorsque la journalisation d’analyse du stockage est configurée. 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.
`x-ms-blob-content-disposition`	facultatif. Définit l'en-tête `Content-Disposition` de l'objet blob. Disponible pour la version 2013-08-15 et ultérieure. Le `Content-Disposition` champ d’en-tête transmet des informations supplémentaires sur la façon de traiter la charge utile de réponse, et il peut être utilisé pour joindre des métadonnées supplémentaires. Par exemple, s’il est défini sur `attachment`, cet en-tête indique que l’agent utilisateur ne doit pas afficher la réponse, mais doit afficher une boîte de dialogue Enregistrer sous. La réponse des opérations Get Blob et Get Blob Properties inclut l’en-tête content-disposition.
`x-ms-access-tier`	facultatif. Version 2018-11-09 et ultérieures. Indique le niveau à définir sur un objet blob. Pour les objets blob de blocs, cet en-tête est pris en charge sur les comptes de stockage d’objets blob ou v2 à usage général uniquement avec la version 2018-11-09 et ultérieure. Les valeurs valides pour les niveaux d’objet blob de blocs sont `Hot`, `Cool`, `Cold`et `Archive`. Remarque : `Cold` le niveau est pris en charge pour la version 2021-12-02 et ultérieure. Pour plus d’informations sur la hiérarchisation des objets blob de blocs , consultez Niveaux de stockage chaud, froid et archive.
`x-ms-immutability-policy-until-date`	Version 2020-06-12 et ultérieures. Spécifie la date de rétention jusqu’à définir sur l’objet blob. Il s’agit de la date jusqu’à laquelle l’objet blob peut être protégé contre la modification ou la suppression. Suit RFC1123 format.
`x-ms-immutability-policy-mode`	Version 2020-06-12 et ultérieures. Spécifie le mode de stratégie d’immuabilité à définir sur l’objet blob. Les valeurs valides sont `unlocked` et `locked`. La `unlocked` valeur indique que les utilisateurs peuvent modifier la stratégie en augmentant ou en diminuant la date de rétention jusqu’à . La `locked` valeur indique que ces actions sont interdites.
`x-ms-legal-hold`	Version 2020-06-12 et ultérieures. Spécifie la conservation légale à définir sur l’objet blob. Les valeurs valides sont `true` et `false`.
`x-ms-expiry-option`	facultatif. Version 2023-08-03 et ultérieures. Spécifie l’option de date d’expiration pour la demande, consultez ExpiryOption. Cet en-tête est valide pour les comptes avec l’espace de noms hiérarchique activé.
`x-ms-expiry-time`	facultatif. Version 2023-08-03 et ultérieures. Spécifie l’heure à laquelle l’objet blob est défini pour expirer. Le format de la date d’expiration varie en fonction de `x-ms-expiry-option`. Pour plus d’informations, consultez ExpiryOption. Cet en-tête est valide pour les comptes avec l’espace de noms hiérarchique activé. Le `expiryTime` déjà présent sur un objet blob n’est pas effacé si la demande ne contient pas de nouvelle valeur de `expiryTime`

Cette opération prend également en charge l'utilisation d'en-têtes conditionnels pour valider la liste noire uniquement si une condition est remplie. Pour plus d’informations, consultez Spécifier des en-têtes conditionnels pour les opérations de stockage Blob.

En-têtes de requête (clés de chiffrement fournies par le client)

À partir de la version 2019-02-02, vous pouvez spécifier les en-têtes suivants sur la demande de chiffrement d’un objet blob avec une clé fournie par le client. Le chiffrement avec une clé fournie par le client (et l’ensemble d’en-têtes correspondant) est facultatif.

En-tête de requête	Description
`x-ms-encryption-key`	Obligatoire. Clé de chiffrement AES-256 encodée en Base64.
`x-ms-encryption-key-sha256`	Obligatoire. Hachage SHA256 codé en Base64 de la clé de chiffrement.
`x-ms-encryption-algorithm: AES256`	Obligatoire. Spécifie l’algorithme à utiliser pour le chiffrement. La valeur de cet en-tête doit être définie `AES256`.

Corps de la demande

Dans le corps de la demande, vous pouvez spécifier la liste de blocs que le Stockage Blob doit case activée pour le bloc demandé. De cette façon, vous pouvez mettre à jour un objet blob existant en insérant, en remplaçant ou en supprimant des blocs individuels, plutôt que de recharger l’ensemble de l’objet blob. Une fois que vous avez chargé le ou les blocs qui ont été modifiés, vous pouvez valider une nouvelle version de l’objet blob en validant les nouveaux blocs avec les blocs existants que vous souhaitez conserver.

Pour mettre à jour un objet blob, vous pouvez spécifier que le service doit rechercher un ID de bloc dans la liste de blocs validés, dans la liste de blocs non validés, ou dans la liste de blocs non validés d'abord, puis dans la liste de blocs validés. Pour indiquer l’approche à utiliser, spécifiez l’ID de bloc qui se trouve dans l’élément XML approprié dans le corps de la requête, comme suit :

Spécifiez l’ID de bloc dans l’élément Committed pour indiquer que Stockage Blob doit rechercher uniquement le bloc nommé dans la liste de blocs validée. Si le bloc est introuvable dans la liste de blocs validée, il n’est pas écrit dans le cadre de l’objet blob, et le Stockage Blob retourne status code 400 (Requête incorrecte).
Spécifiez l’ID de bloc dans l’élément Uncommitted pour indiquer que Stockage Blob doit rechercher uniquement le bloc nommé dans la liste de blocs non validées. Si le bloc est introuvable dans la liste des blocs non validés, il n’est pas écrit dans le cadre de l’objet blob, et le Stockage Blob retourne status code 400 (Requête incorrecte).
Spécifiez l’ID de bloc dans l’élément Latest pour indiquer que Stockage Blob doit d’abord rechercher dans la liste de blocs non validées. Si le bloc se trouve dans la liste de blocs non validés, cette version du bloc est la plus récente et doit être écrite dans l'objet blob. Si le bloc est introuvable dans la liste non validée, le service doit rechercher le bloc nommé dans la liste de blocs validée et écrire ce bloc dans l’objet blob s’il est trouvé.

Le corps de la demande pour cette version de Put Block List utilise le format XML suivant :

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>

Exemple de requête

Pour illustrer Put Block List, supposons que vous avez chargé trois blocs que vous souhaitez maintenant valider. L'exemple suivant valide un nouvel objet blob en indiquant que la version la plus récente de chaque bloc indiqué doit être utilisée. Il n'est pas nécessaire de savoir si ces blocs ont déjà été validés.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>

Supposons ensuite que vous souhaitiez mettre à jour l’objet blob. Le nouvel objet blob présente les modifications suivantes :

Un nouveau bloc avec l'ID ANAAAA==. Ce bloc doit d’abord être chargé avec un appel à Put Block, et il apparaît dans la liste des blocs non validés jusqu’à l’appel à Put Block List.
Une version mise à jour du bloc avec l'ID AZAAAA==. Ce bloc doit d’abord être chargé avec un appel à Put Block, et il apparaît dans la liste des blocs non validés jusqu’à l’appel à Put Block List.
Suppression du bloc avec l'ID AAAAAA==. Étant donné que ce bloc n’est pas inclus dans l’appel suivant à Put Block List, le bloc est effectivement supprimé de l’objet blob.

L'exemple suivant montre l'appel à Put Block List qui met à jour l'objet blob :

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>

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 renvoie le code d'état 201 (Créé).

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.

response	Descriptions
`ETag`	La balise d'entité contient une valeur que le client peut utiliser pour effectuer des opérations `GET/PUT` conditionnelles en utilisant l'en-tête de demande `If-Match`. Si la version de la demande est 2011-08-18 ou version ultérieure, la valeur ETag est placée entre guillemets.
`Last-Modified`	Date et heure de la dernière modification apportée à l'objet blob. Le format de date est conforme à la RFC 1123. Pour plus d’informations, consultez Représenter des valeurs de date/heure dans les en-têtes. Toute opération qui modifie l'objet blob, notamment une mise à jour des métadonnées ou des propriétés de l'objet blob, modifie l'heure de la dernière modification de l'objet blob.
`Content-MD5`	Retourné afin que le client puisse case activée pour l’intégrité du contenu du message. Cet en-tête fait référence au contenu de la requête (dans ce cas, la liste des blocs et non le contenu de l’objet blob lui-même). Pour les versions 2019-02-02 et ultérieures, cet en-tête est retourné uniquement lorsque la requête contient cet en-tête.
`x-ms-content-crc64`	Pour les versions 2019-02-02 et ultérieures, cet en-tête est retourné afin que le client puisse case activée pour l’intégrité du contenu du message. Cet en-tête fait référence au contenu de la requête (dans ce cas, la liste des blocs et non le contenu de l’objet blob lui-même). Cet en-tête est retourné quand l’en-tête `Content-md5` n’est pas présent dans la demande.
`x-ms-request-id`	Identifie de manière unique la demande qui a été effectuée et vous pouvez l’utiliser pour résoudre les problèmes de la demande. Pour plus d’informations, consultez Résoudre les problèmes liés aux opérations d’API.
`x-ms-version`	Version du Stockage Blob utilisée pour exécuter la demande. Cet en-tête est retourné pour les demandes effectuées par rapport à la version 2009-09-19 et ultérieure.
`Date`	Valeur de date/heure UTC générée par le service, qui indique quand la réponse a été lancée.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 et ultérieures. La valeur de cet en-tête est définie sur si le contenu de la demande est correctement chiffré à `true` l’aide de l’algorithme spécifié. Sinon, la valeur est `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 et ultérieures. Cet en-tête est retourné si la demande a utilisé une clé fournie par le client pour le chiffrement, afin que le client puisse s’assurer que le contenu de la demande est correctement chiffré à l’aide de la clé fournie.
`x-ms-encryption-scope`	Version 2019-02-02 et ultérieures. Cet en-tête est retourné si la demande a utilisé une étendue de chiffrement, de sorte que le client peut s’assurer que le contenu de la demande est correctement chiffré à l’aide de l’étendue de chiffrement.
`x-ms-version-id: <DateTime>`	Version 2019-12-12 et ultérieures. Retourne une valeur opaque `DateTime` qui identifie de manière unique l’objet blob. La valeur de cet en-tête indique la version de l’objet blob et peut être utilisée dans les demandes suivantes d’accès à l’objet blob.
`x-ms-client-request-id`	Peut être utilisé pour résoudre les demandes et leurs 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 n’est pas présent dans la réponse.

Exemple de réponse

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

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 Put Block List comme décrit ci-dessous.

Si une requête spécifie des balises avec l’en-tête de x-ms-tags demande, l’appelant doit répondre aux exigences d’autorisation de l’opération Définir des balises blob .

Important

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

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, une identité managée ou un principal de service Microsoft Entra appelle l’opérationPut Block List, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rôle intégré le moins privilégié :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 l’accès aux données d’objets 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 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 SAP.

L’opération Put Block List prend en charge trois types de signatures d’accès partagé : sas de délégation d’utilisateur, SAP de service et SAP de compte.

Comme meilleure pratique de sécurité, nous vous recommandons d’utiliser Microsoft Entra informations d’identification plutôt que la clé de compte de stockage, qui peut être plus facilement compromise. Si la conception de votre application nécessite des signatures d’accès partagé, utilisez Microsoft Entra informations d’identification pour créer une sap de délégation d’utilisateur, si possible.

Lorsque l’accès à la clé partagée est interdit pour le compte de stockage, un jeton SAP de service ou un jeton SAP de compte ne sont pas autorisés lors d’une demande adressée au stockage Blob. Pour plus d’informations, consultez Comprendre comment l’interdiction de la clé partagée affecte les jetons SAP.

SAP de délégation d’utilisateur

Une sap de délégation d’utilisateur est sécurisée avec des informations d’identification Microsoft Entra ainsi que par les autorisations spécifiées pour la sap.

L’appel de l’opération à l’aide Put Block List d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation Write (w) dans le cadre du jeton SAP de délégation utilisateur.

Pour en savoir plus sur la sap de délégation d’utilisateur, consultez Create une SAP de délégation d’utilisateur.

SAP de service

Une SAP de service est sécurisée à l’aide de la clé de compte de stockage. Une sap de service délègue l’accès à une ressource dans un seul service Stockage Azure, tel que le stockage blob.

L’appel de l’opération à l’aide Put Block List d’un jeton SAP délégué à un conteneur ou à une ressource blob nécessite l’autorisation Write (w) dans le cadre du jeton SAP de service.

Pour en savoir plus sur la SAP de service, consultez Create une SAP de service.

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
Put Block List	Objet blob (b)	Objet (o)	Écriture (w)

Pour en savoir plus sur la SAP de compte, consultez Create une SAP de compte.

L’opération Put Block List prend en charge l’autorisation de clé partagée. L’autorisation avec des clés de compte n’est pas recommandée dans 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'opération Put Block List définit l'ordre dans lequel les blocs doivent être combinés pour créer un objet blob.

Le même ID de bloc peut être spécifié plusieurs fois dans la liste de blocs. Si un ID de bloc est spécifié plusieurs fois, il représente la plage d’octets dans chacun de ces emplacements dans la liste de blocs pour l’objet blob validé final. Si un ID de bloc s'affiche plusieurs fois dans la liste, les deux instances de l'ID de bloc doivent être spécifiées dans la même liste de blocs. En d'autres termes, les deux instances doivent être spécifiées dans l'élément Committed, l'élément Uncommitted, ou l'élément Latest.

Avec Put Block List, vous pouvez modifier un objet blob existant en insérant, en mettant à jour ou en supprimant des blocs individuels sans avoir à charger à nouveau l’ensemble de l’objet blob. Vous pouvez spécifier des ID de bloc de la liste de blocs validés et de la liste de blocs non validés pour créer un nouvel objet blob ou pour mettre à jour le contenu d'un objet blob existant. De cette façon, vous pouvez mettre à jour un objet blob en spécifiant quelques nouveaux blocs de la liste de blocs non validées et le reste à partir de la liste de blocs validée, qui font déjà partie de l’objet blob existant.

Si un ID de blocs est spécifié dans l'élément Latest, et que le même ID de bloc existe dans la liste de blocs validés et dans la liste de blocs non validés, Put Block List valide le bloc de la liste de blocs non validés. Si l’ID de bloc existe dans la liste de blocs validée, mais pas dans la liste de blocs non validée, Put Block List valide le bloc à partir de la liste de blocs validée.

Chaque bloc d’un objet blob de blocs peut avoir une taille différente. Un objet blob de blocs peut inclure un maximum de 50 000 blocs validés. Le nombre maximal de blocs non validés qui peuvent être associés à un objet blob est de 100 000.

Le tableau suivant décrit les tailles maximales autorisées de blocs et d’objets blob, par version de service :

Version du service	Taille maximale du bloc (via `Put Block`)	Taille maximale de l’objet blob (via `Put Block List`)	Taille maximale de l’objet blob via une opération d’écriture unique (via `Put Blob`)
Version 2019-12-12 et ultérieure	4 000 mebioctets (MiO)	Environ 190,7 tebibytes (Tio) (4 000 Mio × 50 000 blocs)	5 000 Mio
Versions 31-05-2016 à 2019-07-07	100 Mio	Environ 4,75 Tio (100 Mio × 50 000 blocs)	256 Mio
Versions antérieures au 31/05/2016	4 Mio	Environ 195 Gio (4 Mio × 50 000 blocs)	64 Mio

Lorsque vous appelez Put Block List pour mettre à jour un objet blob existant, les propriétés et les métadonnées existantes de l'objet blob sont remplacées. Toutefois, tous les instantanés existants sont conservés avec l'objet blob. Vous pouvez utiliser les en-têtes de demande conditionnels pour exécuter cette opération uniquement si une condition donnée est remplie.

Si l’opération Put Block List échoue en raison d’un bloc manquant, vous devez charger le bloc manquant.

Tous les blocs non validés sont collectés par le garbage s’il n’y a pas d’appels réussis vers Put Block ou Put Block List sur l’objet blob dans la semaine suivant la dernière opération réussie Put Block . Si Put Blob est appelé sur l’objet blob, tous les blocs non validés sont collectés par la mémoire.

Si les balises sont fournies dans l’en-tête x-ms-tags , elles doivent être encodées sous forme de chaîne de requête. Les clés et les valeurs de balise doivent être conformes aux exigences de nommage et de longueur, comme spécifié dans Set Blob Tags. En outre, l’en-tête x-ms-tags peut contenir des étiquettes d’une taille maximale de 2 Kio. Si d’autres balises sont requises, utilisez l’opération Définir des balises blob .

Si l’objet blob a un bail actif, le client doit spécifier un ID de bail valide sur la demande de validation de la liste de blocs. Si le client ne spécifie pas d’ID de bail ou qu’il spécifie un ID de bail non valide, Stockage Blob retourne status code 412 (Échec de la condition préalable). Si le client spécifie un ID de bail mais que l’objet blob n’a pas de bail actif, stockage Blob retourne également status code 412 (Échec de la condition préalable). Si le client spécifie un ID de bail sur un objet blob qui n’existe pas encore, Stockage Blob retourne status code 412 (Échec de la condition préalable) pour les demandes effectuées sur la version 2013-08-15 ou ultérieure. Pour les versions antérieures, Stockage Blob retourne status code 201 (Créé).

Si l'objet blob a un bail actif et que vous appelez Put Block List pour mettre à jour l'objet blob, le bail est conservé dans l'objet blob mis à jour.

Put Block List s'applique uniquement aux objets blob de blocs. L'appel de Put Block List sur un objet blob de pages produit un code d'état 400 (Demande incorrecte).

Le remplacement d’un objet blob archivé échoue et le remplacement d’un hot objet blob ou cool hérite du niveau de l’ancien blob si l’en-tête x-ms-access-tier n’est pas fourni.

Facturation

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

Opération	Type de compte de stockage	Catégorie de facturation
Put Block List	Objet blob de blocs Premium Usage général v2 Standard 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 Stockage Blob Azure Tarification.

Voir aussi

Comprendre les objets blob de blocs, les objets blob d’ajout et les objets blob de pages
Autoriser les demandes à Stockage Azure
Codes d’état et d’erreur
Codes d’erreur du service Blob
Définir des délais d’attente pour les opérations de service Blob

Partager via