Put Block List

L'opération Put Block List écrit un objet blob en spécifiant la liste des ID de bloc qui le composent. Pour pouvoir être écrit dans le cadre d’un objet BLOB, un bloc doit avoir été correctement écrit sur le serveur dans une opération de bloc put précédente.

Vous pouvez appeler Put Block List pour mettre à jour un objet blob en téléchargeant uniquement les blocs qui ont changé, puis en validant les blocs nouveaux et existants. Vous pouvez faire cela en spécifiant si un bloc doit être validé à partir de la liste de blocs validés ou de la liste de blocs non validés, ou si la version du bloc téléchargée en dernier doit être validée en indiquant la liste auquel le bloc appartient.

Requête

La demande Put Block List peut être construite comme indiqué ci-dessous. HTTPS est recommandé. Remplacez moncompte par le nom de votre compte de stockage :

URI de demande de la méthode PUT Version HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1

URI du service de stockage émulé

Lorsque vous élaborez une demande pour le service de stockage émulé, spécifiez le nom d'hôte de l'émulateur et le port de service BLOB sous la forme 127.0.0.1:10000, suivi du nom de compte de stockage émulé :

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

L’émulateur de stockage prend uniquement en charge les tailles d’objet BLOB allant jusqu’à 2 Gio.

pour plus d’informations, consultez utilisation du Emulator stockage Azure pour le développement et le test.

Paramètres URI

Les paramètres supplémentaires suivants peuvent être spécifiés dans l'URI de la demande.

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

En-têtes de requête

Le tableau suivant décrit les en-têtes de demande obligatoires ou facultatifs.

En-tête de requête Description
Authorization Obligatoire. Spécifie le schéma d’autorisation, le nom de compte et la signature. pour plus d’informations, consultez autoriser les demandes à 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 demandes à 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 contrôle de version pour les Services stockage Azure.
Content-Length Obligatoire. La longueur du contenu de la demande, en octets. Cet en-tête fait référence à la longueur de contenu de la liste de 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 demande, 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 demande, 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 (demande incorrecte).

Cet en-tête est pris en charge dans versions2019-02-02 ou version ultérieure.
x-ms-blob-cache-control Facultatif. Définit le contrôle du cache 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 cette propriété n'est pas spécifiée avec la demande, elle est supprimé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 cette propriété n'est pas spécifiée avec la demande, elle est supprimée pour l'objet blob si la demande réussit.
x-ms-blob-content-language Facultatif. Définit la langue 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 cette propriété n'est pas spécifiée avec la demande, elle est supprimé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 pour les blocs individuels ont été validés lors du chargement de chaque.

L’opération d' extraction d’objets 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 supprimée pour l'objet blob si la demande réussit.
x-ms-meta-name:value Facultatif. Paires nom-valeur définies par l'utilisateur associées à l'objet blob.

À partir de la version 2009-09-19, les noms de métadonnées doivent respecter les règles d’affectation de noms pour les identificateurs C#.
x-ms-encryption-scope Facultatif. Indique l’étendue de chiffrement à utiliser pour chiffrer l’objet BLOB. Cette valeur doit correspondre à la portée de chiffrement utilisée pour chiffrer tous les blocs en cours de validation. Cet en-tête est pris en charge dans les versions 2019-02-02 ou ultérieures.
x-ms-tags Facultatif. Définit les balises encodées de chaîne de requête données sur l’objet BLOB. Pour plus d’informations, consultez les notes. Pris en charge dans la version 2019-12-12 et les versions 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 1 Kio de caractères qui est enregistrée dans les journaux d’analyse lorsque la journalisation de l’analyse de stockage est activée. L’utilisation de cet en-tête est fortement recommandée pour la mise en corrélation des activités côté client avec les requêtes reçues par le serveur. pour plus d’informations, consultez à propos de la journalisation des Storage Analytics et de la journalisation Azure : utilisation des journaux pour suivre les demandes de Stockage.
x-ms-blob-content-disposition Facultatif. Définit l'en-tête Content-Disposition de l'objet blob. Disponible pour la version du 15/08/2013 et les versions ultérieures.

Le champ d'en-tête Content-Disposition donne des informations supplémentaires sur la manière de traiter la charge utile de réponse, et peut également être utilisé pour attacher des métadonnées supplémentaires. Par exemple, s'il est défini à la valeur attachment, il indique que l'agent utilisateur ne doit pas afficher la réponse, mais une boîte de dialogue Enregistrer sous.

La réponse des opérations d' extraction d’objet BLOB et d' extraction de propriétés d’objet BLOB comprend l’en-tête Content-disposition.
x-ms-access-tier Facultatif. Version 2018-11-09 et versions ultérieures. Indique le niveau à définir sur un objet BLOB. Pour les objets BLOB de blocs, pris en charge sur les comptes stockage BLOB ou usage général v2 uniquement avec la version 2018-11-09 et les versions ultérieures. Les valeurs valides pour les niveaux d’objet blob de blocs sont Hot / Cool / Archive . 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 versions ultérieures. Spécifie la date de rétention jusqu’à ce qu’elle soit définie sur l’objet BLOB. Il s’agit de la date jusqu’à laquelle la protection de l’objet BLOB peut être modifiée ou supprimée. Suit le format RFC1123.
x-ms-immutability-policy-mode Version 2020-06-12 et versions ultérieures. Spécifie le mode de stratégie d’immuabilité à définir sur l’objet BLOB. Les valeurs valides sont unlocked / locked . unlocked indique que l’utilisateur peut modifier la stratégie en accroissant ou en diminuant la date de rétention jusqu’à la date. locked indique que ces actions sont interdites.
x-ms-legal-hold Version 2020-06-12 et versions ultérieures. Spécifie la conservation légale à définir sur l’objet BLOB. les valeurs valides sont true/false .

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écification des en-têtes conditionnels pour les opérations du service Blob.

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

À partir de la version 2019-02-02, les en-têtes suivants peuvent être spécifiés sur la demande pour chiffrer un objet BLOB avec une clé fournie par le client. Le chiffrement avec une clé fournie par le client (et le jeu 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 encodé 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 service BLOB doit vérifier pour le bloc demandé. De cette façon, vous pouvez mettre à jour un objet BLOB existant en insérant, remplaçant ou supprimant des blocs individuels, au lieu de retélécharger l’objet BLOB entier. Après avoir téléchargé les blocs modifiés, vous pouvez valider une nouvelle version de l'objet BLOB en validant les nouveaux blocs en même temps que 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 dans l'élément XML approprié au sein du corps de la demande, comme suit :

  • Spécifiez l'ID de bloc dans l'élément Committed pour indiquer que le service BLOB doit rechercher le bloc nommé uniquement dans la liste de blocs validés. Si le bloc est introuvable dans la liste de blocs validés, il n'est pas écrit dans l'objet blob, et le service BLOB retourne le code d'état 400 (Demande incorrecte).

  • Spécifiez l'ID de bloc dans l'élément Uncommitted pour indiquer que le service BLOB doit rechercher le bloc nommé uniquement dans la liste de blocs non validés. Si le bloc est introuvable dans la liste de blocs non validés, il n'est pas écrit dans l'objet blob, et le service BLOB retourne le code d'état 400 (Demande incorrecte).

  • Spécifiez l'ID de bloc dans l'élément Latest pour indiquer que le service BLOB doit en premier rechercher le bloc nommé dans la liste de blocs non validés. 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 de blocs non validés, le service doit rechercher le bloc nommé dans la liste de blocs validés et écrire ce bloc dans l'objet blob s'il le trouve.

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 demande

Pour illustrer Put Block List, supposez que vous avez téléchargé trois blocs que vous voulez 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>  
  

Ensuite, supposez que vous voulez mettre à jour l'objet blob. Ce nouvel objet blob contiendra les modifications suivantes :

  • Un nouveau bloc avec l'ID ANAAAA==. Ce bloc doit d’abord être téléchargé avec un appel au bloc put et s’afficher dans la liste de 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 téléchargé avec un appel au bloc put et s’afficher dans la liste de 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 sera 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  
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>  
  

Réponse

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 d’État, 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.

Réponse 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 18/08/2011 ou plus récente, la valeur de l'ETag sera 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ésentation des valeurs de Date-Time 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 Cet en-tête est renvoyé afin que le client puisse vérifier l'intégrité du contenu du message. Cet en-tête fait référence au contenu de la demande, ce qui signifie dans ce cas, la liste de blocs, et non le contenu de l'objet blob lui-même. Pour versions2019-02-02 ou version ultérieure, cet en-tête est retourné uniquement lorsque la requête a 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 vérifier l’intégrité du contenu du message. Cet en-tête fait référence au contenu de la demande, ce qui signifie dans ce cas, la liste de blocs, et non le contenu de l'objet blob lui-même.

Cet en-tête est retourné lorsque Content-md5 l’en-tête n’est pas présent dans la demande.
x-ms-request-id Cet en-tête identifie de façon 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, consultez Troubleshooting API Operations.
x-ms-version Indique la version du service BLOB utilisée pour exécuter la demande. Cet en-tête est renvoyé pour les demandes effectuées avec la version 2009-09-19 ou une version ultérieure.
Date Une valeur de date/heure UTC générée par le service qui indique le moment auquel la réponse a été initiée.
x-ms-request-server-encrypted: true/false Version 2015-12-11 ou ultérieure. La valeur de cet en-tête est définie sur true si le contenu de la demande est correctement chiffré à l’aide de l’algorithme spécifié et dans le false cas contraire.
x-ms-encryption-key-sha256 Version 2019-02-02 ou ultérieure. Cet en-tête est retourné si la demande utilise 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 ou ultérieure. Cet en-tête est retourné si la demande a utilisé une étendue de chiffrement, afin que le client puisse 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 versions ultérieures. Cet en-tête retourne une DateTime valeur opaque qui identifie de façon 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 pour accéder à l’objet BLOB.
x-ms-client-request-id Cet en-tête peut être utilisé pour dépanner les demandes et les réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l' x-ms-client-request-id en-tête si elle est présente dans la demande et que la valeur est supérieure à 1024 caractères ASCII visibles. Si l' x-ms-client-request-id en-tête n’est pas présent dans la demande, cet en-tête ne sera 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

Cette opération peut être appelée par le propriétaire du compte ou par toute personne avec une signature d'accès partagé qui dispose des autorisations pour écrire dans cet objet blob ou son conteneur.

Si une demande spécifie des balises avec l' x-ms-tags en-tête de demande, l’appelant doit respecter les exigences d’autorisation de l’opération définir les balises d’objet BLOB .

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ésentera la plage d'octets dans chacun de ces emplacements dans la liste de blocs pour l'objet blob final validé. 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 lors de l'insertion, de la mise à jour, ou de la suppression de blocs individuels, sans télécharger l'objet blob en entier. 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és, et le reste de la liste de blocs validés, 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és mais pas dans la liste de blocs non validés, alors Put Block List valide le bloc de la liste de blocs non validés.

Chaque bloc dans 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 de blocs et d’objets BLOB autorisées par la version du service :

Version du service Taille de bloc maximale (via Put Block) Taille de blob maximale (via Put Block List) Taille de blob maximale via une seule opération d’écriture (via Put Blob)
Version 2019-12-12 et ultérieure 4 000 Mio Environ 190,7 Tio (4 000 Mio X 50 000 blocs) 5 000 Mio (préversion)
De la version 2016-05-31 à la version 2019-07-07 100 Mio Environ 4,75 Tio (100 Mio X 50 000 blocs) 256 Mio
Versions antérieures à 2016-05-31 4 Mio Environ 195 Gio (4 Mio X 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 télécharger le bloc manquant.

Tous les blocs non validés seront récupérés par le garbage collector s'il n'existe aucun appel réussi à Put Block ou à Put Block List sur l'objet blob dans la semaine qui suit la dernière opération Put Block réussie. Si l' objet BLOB put est appelé sur l’objet BLOB, tous les blocs non validés seront récupérés par le garbage collector.

Si des balises sont fournies dans l' x-ms-tags en-tête, elles doivent être codées en chaîne de requête. Les clés et valeurs de balise doivent respecter les exigences de nommage et de longueur comme spécifié dans définir des balises d’objet BLOB. En outre, l' x-ms-tags en-tête peut contenir des balises d’une taille maximale de 2 Kio. Si davantage de balises sont requises, utilisez l’opération définir les balises d’objet BLOB .

Si l'objet blob a un bail actif, le client doit spécifier un ID de bail valide dans la demande afin de valider la liste de blocs. Si le client ne spécifie pas un ID de bail ou spécifie un ID de bail incorrect, le service BLOB retourne le code d'état 412 (Échec de la précondition). Si le client spécifie un ID de bail, mais que l'objet blob n'a pas de bail actif, le service BLOB retourne également le code d'état 412 (Échec de la précondition). Si le client spécifie un ID de bail sur un objet blob qui n'existe pas encore, le service BLOB retourne le code d'état 412 (Échec de la précondition) pour les requêtes effectuées avec la version du 15/08/2013 et les versions ultérieures ; pour les versions antérieures, le service BLOB retourne le code d'état 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 / cool objet BLOB hérite du niveau de l’ancien objet blob Si l’en-tête x-MS-Access-Tier n’est pas fourni.

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éfinition de délais d'expiration pour les opérations du service BLOB