Placer une liste de blocs

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

Vous pouvez appeler Put Block List pour mettre à jour un blob en ne téléchargeant que les blocs qui ont changé, puis en regroupant les blocs nouveaux et existants. Vous pouvez le faire en spécifiant s’il faut valider un bloc depuis la liste de blocage d’engagement ou de la liste de blocage non engagée, ou bien en commençant la version la plus récente du bloc, quelle que soit la liste à laquelle il appartient.

Requête

Vous pouvez construire la requête Put Block List comme suit. Nous vous recommandons d’utiliser HTTPS. Remplacez myaccount 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 faites une requête sur le 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, suivis 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 de blob allant jusqu’à 2 Gibioctets (Gio) seulement.

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

Paramètres d’URI

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

Paramètre Description
timeout Optionnel. Le paramètre timeout est exprimé en secondes. Pour plus d’informations, voir Définir les 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 demandes vers le stockage Azure.
Date ou x-ms-date Obligatoire. 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-version Obligatoire pour toutes les demandes autorisées. Spécifie la version de l’opération à utiliser pour cette requête. Pour plus d’informations, consultez Contrôle de version pour les services stockage Azure.
Content-Length Obligatoire. La longueur du contenu de la requête, en octets. Cet en-tête fait référence à la longueur du contenu de la liste des blocs, et non à la blob elle-même.
Content-MD5 Optionnel. Hachage MD5 du contenu de la requête. Ce hachage est utilisé pour vérifier l’intégrité du contenu de la requête 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 du blob lui-même.
x-ms-content-crc64 Optionnel. Un hachage CRC64 du contenu de la requête. Ce hachage est utilisé pour vérifier l’intégrité du contenu de la requête 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 du blob lui-même.

Si les en-têtes Content-MD5 et x-ms-content-crc64 sont présents, la requête échoue avec un 400 (mauvaise requête).

Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
x-ms-blob-cache-control Optionnel. Définit le contrôle du cache du blob. Si cette propriété est spécifiée, elle est stockée avec le blob et renvoyée avec une requête de lecture.

Si la propriété n’est pas spécifiée avec la requête, elle est effacée pour le blob si la requête est réussie.
x-ms-blob-content-type Optionnel. Définit le type de contenu du blob. Si elle est spécifiée, cette propriété est stockée avec le blob et renvoyée avec une requête 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 Optionnel. Définit l’encodage du contenu du blob. Si elle est spécifiée, cette propriété est stockée avec le blob et renvoyée avec une requête de lecture.

Si la propriété n’est pas spécifiée avec la requête, elle est effacée pour le blob si la requête est réussie.
x-ms-blob-content-language Optionnel. Définit le langage du contenu du blob. Si elle est spécifiée, cette propriété est stockée avec le blob et renvoyée avec une requête de lecture.

Si la propriété n’est pas spécifiée avec la requête, elle est effacée pour le blob si la requête est réussie.
x-ms-blob-content-md5 Optionnel. Hachage MD5 du contenu de l’objet blob. Ce hachage n’est pas validé, car les hachages des blocs individuels ont été validés lors de leur téléchargement.

L’opération Get Blob renvoie 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 requête, elle est effacée pour le blob si la requête est acceptée.
x-ms-meta-name:value Optionnel. Des paires nom-valeur définies par l’utilisateur associées au blob.

Depuis la version 2009-09-19, les noms de métadonnées doivent respecter les règles de dénomination des identifiants C#.
x-ms-encryption-scope Optionnel. Indique le champ de chiffrement à utiliser pour chiffrer le blob. Cette valeur doit correspondre à l’étendue de chiffrement utilisée pour chiffrer tous les blocs en cours de commission. Cet en-tête est pris en charge dans la version 2019-02-02 et ultérieure.
x-ms-encryption-context Optionnel. Par défaut, c’est « Vide ». Si la valeur est définie, elle définira les métadonnées du système blob. 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 Optionnel. Définit les balises codées par la chaîne de requêtes spécifiées sur le blob. Pour plus d’informations, voir la section Remarques . Prise en charge dans la version 2019-12-12 et ultérieure.
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 Optionnel. Fournit une valeur opaque générée par le client avec une limite de caractères de 1 kibioctet (KiB) qui est enregistrée dans les journaux analytiques lors de la configuration des journaux d’analyse de stockage. 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 Optionnel. Définit l’en-tête de la Content-Disposition masse. Disponible pour la version 2013-08-15 et ultérieure.

Le champ d’en-tête Content-Disposition transmet des informations supplémentaires sur la manière de traiter la charge utile de la réponse, et il peut être utilisé pour joindre des métadonnées supplémentaires. Par exemple, si elle est définie sur attachment, cet en-tête indique que l’agent-utilisateur ne doit pas afficher la réponse, mais doit plutôt afficher un dialogue Enregistrer en tant que.

La réponse des opérations Get Blob et Get Blob Properties inclut l’en-tête content-disponance.
x-ms-access-tier Optionnel. Version 2018-11-09 et ultérieure. Indique le niveau à définir sur un blob. Pour les blobs de blocs, cet en-tête est pris en charge uniquement sur le stockage de blobs ou les comptes v2 à usage général à partir de la version 2018-11-09. Les valeurs valides pour les niveaux de blobs de blocs sont Hot, Cool, Cold, Smart et Archive.
Note :Cold Tier est pris en charge pour la version 2021-12-02 et ultérieure. Smart Le palier est pris en charge pour la version 2026-02-06 et ultérieure, et est actuellement en aperçu public.
Pour des informations détaillées sur le tiégelage par blocs blob, voir Niveaux de stockage blob.
x-ms-immutability-policy-until-date Version 2020-06-12 et ultérieure. Précise la date de rétention à fixer sur le blob. C’est la date jusqu’à laquelle le blob peut être protégé contre toute modification ou suppression. Suit RFC1123 format.
x-ms-immutability-policy-mode Version 2020-06-12 et ultérieure. Spécifie le mode politique d’immuabilité à définir sur le blob. Les valeurs valides sont unlocked et locked. Cette unlocked valeur indique que les utilisateurs peuvent modifier la politique en augmentant ou diminuant la date de rétention jusqu’à présent. La locked valeur indique que ces actions sont interdites.
x-ms-legal-hold Version 2020-06-12 et ultérieure. Précise la retenue légale à fixer sur le blob. Les valeurs valides sont true et false.
x-ms-expiry-option Optionnel. Version 2023-08-03 et ultérieure. Précise l’option de date d’expiration pour la demande, voir Option d’expiration. Cet en-tête est valable pour les comptes ayant activé l’espace de noms hiérarchique.
x-ms-expiry-time Optionnel. Version 2023-08-03 et ultérieure. Précise le moment auquel le blob doit expirer. Le format de la date d’expiration varie selon x-ms-expiry-option. Pour plus d’informations, voir VincyOption. Cet en-tête est valable pour les comptes ayant activé l’espace de noms hiérarchique.

Le expiryTime contenu déjà présent sur un blob n’est pas effacé si la requête ne contient pas une nouvelle valeur de expiryTime

Cette opération permet également l’utilisation d’en-têtes conditionnels pour valider la liste de blocage uniquement si une condition spécifiée est remplie. Pour plus d’informations, voir Spécifier les en-têtes conditionnels pour les opérations de stockage en blob.

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

Depuis la version 2019-02-02, vous pouvez spécifier les en-têtes suivants sur la demande de chiffrement d’un 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 optionnel.

En-tête de requête Description
x-ms-encryption-key Obligatoire. La clé de chiffrement AES-256 codée en Base64.
x-ms-encryption-key-sha256 Obligatoire. Le 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 AES256.

Corps de la demande

Dans le corps de la demande, vous pouvez spécifier la liste de blocs que Blob Storage doit vérifier pour le bloc demandé. De cette façon, vous pouvez mettre à jour un blob existant en insérant, remplaçant ou supprimant des blocs individuels, plutôt que de re-téléverser l’ensemble du blob. Après avoir téléchargé le ou les blocs qui ont changé, vous pouvez valider une nouvelle version du blob en regroupant les nouveaux blocs avec ceux que vous souhaitez conserver.

Pour mettre à jour un blob, vous pouvez spécifier que le service doit rechercher un identifiant de bloc dans la liste de blocage engagée, dans la liste de blocage non engagée, ou dans la liste de blocage non engagée, puis dans la liste de blocage engagée. Pour indiquer quelle approche utiliser, spécifiez l’identifiant de bloc qui se trouve dans l’élément XML approprié dans le corps de la requête, comme suit :

  • Spécifiez l’identifiant de bloc à l’intérieur de l’élément Committed pour indiquer que Blob Storage ne doit rechercher que dans la liste de blocs engagée le bloc nommé. Si le bloc n’est pas trouvé dans la liste de blocage engagée, il n’est pas écrit dans le blob, et Blob Storage renvoie le code de statut 400 (Mauvaise requête).

  • Spécifiez l’identifiant de bloc dans l’élément Uncommitted pour indiquer que Blob Storage ne doit rechercher que la liste de blocs non engagée pour le bloc nommé. Si le bloc n’est pas trouvé dans la liste de blocage non engagée, il n’est pas écrit dans le blob, et Blob Storage renvoie le code de statut 400 (Mauvaise requête).

  • Spécifiez l’identifiant de bloc dans l’élément Latest pour indiquer que Blob Storage doit d’abord rechercher dans la liste de blocs non engagée. Si le bloc est trouvé dans la liste non engagée, cette version du bloc est la dernière et doit être écrite sur le blob. Si le bloc n’est pas trouvé dans la liste non engagée, le service doit rechercher le bloc nommé dans la liste de blocs engagée et écrire ce bloc dans le blob s’il est trouvé.

Le corps de la requête pour cette version utilise Put Block List 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 démontrer Put Block List, supposons que vous ayez téléchargé trois blocs que vous souhaitez maintenant engager. L’exemple suivant commet un nouveau blob en indiquant que la dernière version de chaque bloc listé doit être utilisée. Il n’est pas nécessaire de savoir si ces blocages ont déjà été commis.

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, supposons que vous souhaitiez mettre à jour le blob. Le nouveau blob présente les changements suivants :

  • Un nouveau bloc avec un ID ANAAAA==. Ce bloc doit d’abord être téléchargé avec un appel à Put Block, et il apparaît dans la liste de blocage non engagée jusqu’à l’appel à Put Block List.

  • Une version mise à jour du bloc avec ID AZAAAA==. Ce bloc doit d’abord être téléchargé avec un appel à Put Block, et il apparaît dans la liste de blocage non engagée jusqu’à l’appel à Put Block List.

  • Retrait du bloc avec l’ID AAAAAA==. Comme ce bloc n’est pas inclus dans le prochain appel à Put Block List, le bloc est effectivement retiré du blob.

L’exemple suivant montre l’appel qui Put Block List met à jour le 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>

Réponse

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 201 (créé).

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.

Réponse Descriptions
ETag L’entité contient une valeur que le client peut utiliser pour effectuer des opérations conditionnelles GET/PUT en utilisant l’en-tête If-Match requête. 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 Date/heure de la dernière modification de l’objet blob. Le format de date suit RFC 1123. Pour plus d’informations, voir Représenter les valeurs date/heure dans les en-têtes.

Toute opération modifiant le blob, y compris une mise à jour des métadonnées ou propriétés du blob, modifie le dernier temps de modification du blob.
Content-MD5 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 requête (dans ce cas, à la liste des blocs et non au contenu du blob lui-même). Pour la version 2019-02-02 et ultérieures, cet en-tête n’est retourné que lorsque la requête possède cet en-tête.
x-ms-content-crc64 Pour la version 2019-02-02 et ultérieure, cet en-tête est renvoyé afin que le client puisse vérifier l’intégrité du contenu des messages. Cet en-tête fait référence au contenu de la requête (dans ce cas, à la liste des blocs et non au contenu du blob lui-même).

Cet en-tête est retourné lorsque Content-md5 l’en-tête n’est pas présent dans la requête.
x-ms-request-id Identifie de manière unique la demande qui a été effectuée et vous pouvez l’utiliser pour résoudre la demande. Pour plus d’informations, consultez Résoudre les problèmes d’opérations d’API.
x-ms-version La version de Blob Storage utilisée pour exécuter la requête. Cet en-tête est retourné pour les requêtes effectuées contre la version 2009-09-19 et ultérieure.
Date Une valeur UTC de date/heure 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érieure. La valeur de cet en-tête est fixée à true si le contenu de la requête est chiffré avec succès à l’aide de l’algorithme spécifié. Sinon, la valeur est définie sur false.
x-ms-encryption-key-sha256 Version 2019-02-02 et ultérieure. Cet en-tête est retourné si la requête a utilisé une clé fournie par le client pour le chiffrement, afin que le client puisse s’assurer que le contenu de la requête est chiffré avec succès en utilisant la clé fournie.
x-ms-encryption-scope Version 2019-02-02 et ultérieure. Cet en-tête est retourné si la requête utilise un scope de chiffrement, afin que le client puisse s’assurer que le contenu de la requête est chiffré avec succès en utilisant le scope de chiffrement.
x-ms-version-id: <DateTime> Version 2019-12-12 et ultérieure. Retourne une valeur DateTime opaque qui identifie de manière unique l’objet blob. La valeur de cet en-tête indique la version du blob, et il peut être utilisé lors de requêtes ultérieures pour accéder au 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 requête, 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>

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

Si une requête spécifie des balises avec l’en-tête x-ms-tags de la requête, l’appelant doit satisfaire aux exigences d’autorisation de l’opération Set Blob Tags.

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.

Stockage Azure prend en charge l’utilisation de Microsoft Entra ID pour l’autorisation des requêtes aux données 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 Put Block List et le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

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.

Remarques

L’opération Put Block List impose l’ordre dans lequel les blocs doivent être combinés pour créer un blob.

Le même identifiant de bloc peut être spécifié plus d’une fois dans la liste des blocs. Si un identifiant 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 le blob final confirmé. Si un identifiant de bloc apparaît plusieurs fois dans la liste, les deux occurrences de cet identifiant doivent être spécifiées dans la même liste de blocs. En d’autres termes, les deux instances doivent être spécifiées à l’intérieur de l’élément Committed , de l’élément Uncommitted ou de l’élément Latest .

Avec Put Block List, vous pouvez modifier un blob existant en insérant, en mettant à jour ou en supprimant des blocs individuels sans avoir à télécharger à nouveau tout le blob. Vous pouvez spécifier des identifiants de bloc à la fois de la liste de blocage engagée actuelle et de la liste de blocage non engagée pour créer un nouveau blob ou mettre à jour le contenu d’un blob existant. De cette façon, vous pouvez mettre à jour un blob en spécifiant quelques nouveaux blocs de la liste de blocage non engagée, et les autres de la liste de blocage engagée, qui font déjà partie du blob existant.

Si un identifiant de bloc est spécifié dans l’élément Latest , et que le même identifiant de bloc existe dans les listes de blocs engagées et non engagées, Put Block List le bloc est validé à partir de la liste non engagée. Si l’identifiant de bloc existe dans la liste de blocage engagée mais pas dans la liste de blocage non engagée, Put Block List le bloc est validé par la liste de blocage engagée.

Chaque bloc dans un blob de blocs peut avoir une taille différente. Un blob de blocs peut inclure un maximum de 50 000 blocs engagés. Le nombre maximal de blocs non engagés pouvant être associés à un blob est de 100 000.

Le tableau suivant décrit les tailles maximales autorisées de blocs et de blobs, par version du service :

Version du service Taille maximale du bloc (via Put Block) Taille maximale de la blob (via Put Block List) Taille maximale de blob via une seule opération d’écriture (via Put Blob)
Version 2019-12-12 et ultérieure 4 000 mébioctets (MiB) Environ 190,7 tebioctets (TiB) (4 000 MiB × 50 000 blocs) 5 000 MiB
Versions du 31-05-2016 au 07-07-2019 100 Mio Environ 4,75 TiB (100 MiB × 50 000 blocs) 256 Mio
Versions antérieures au 31-05-2016 4 Mio Environ 195 GiB (4 MiB × 50 000 blocs) 64 Mio

Lorsque vous appelez Put Block List pour mettre à jour un blob existant, les propriétés et métadonnées existantes du blob sont écrasées. Cependant, tous les instantanés existants sont conservés avec le blob. Vous pouvez utiliser les en-têtes de requête conditionnelle pour effectuer l’opération uniquement si une condition spécifiée est remplie.

Si l’opération Put Block List échoue à cause d’un bloc manquant, vous devez télécharger ce bloc manquant.

Tout blocage non engagé est récupéré à la poubelle s’il n’y a pas d’appels réussis vers Put Block ou Put Block List sur le blob dans la semaine suivant la dernière opération réussie Put Block . Si Put Blob est appelé sur le blob, tous les blocs non engagés sont récupérés par la récupération.

Si des balises sont fournies dans l’en-tête x-ms-tags , elles doivent être encodées par une chaîne de requête. Les clés et valeurs de balise doivent respecter les exigences de nommage et de longueur, telles que spécifiées dans Set Blob Tags. De plus, l’en-tête x-ms-tags peut contenir des balises pouvant atteindre 2 KiB. Si plus de tags sont nécessaires, utilisez l’opération Set Blob Tags.

Si le blob possède un bail actif, le client doit spécifier un identifiant de bail valide sur la requête de validation de la liste de blocage. Si le client ne spécifie pas d’identifiant de bail ou un identifiant de bail invalide, Blob Storage renvoie le code de statut 412 (Échec de la précondition). Si le client spécifie un identifiant de bail mais que le blob n’a pas de bail actif, Blob Storage restitue également le code de statut 412 (Échec de la précondition). Si le client spécifie un identifiant de bail sur un bloc qui n’existe pas encore, Blob Storage renvoie le code de statut 412 (Échec de la précondition) pour les requêtes effectuées à partir de la version 2013-08-15 ou ultérieure. Pour les versions antérieures, Blob Storage restitue le code de statut 201 (Créé).

Si le blob a un bail actif et que vous appelez Put Block List pour mettre à jour le blob, le bail est maintenu sur le blob mis à jour.

Put Block List S’applique uniquement aux blocs de bloc. Appeler Put Block List un blob de page donne le code de statut 400 (mauvaise requête).

Écraser un archive blob échoue. Sinon, un blob hérite du tier de l’ancien blob si aucun x-ms-access-tier en-tête n’est fourni.

Facturation

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 Put Block List en fonction du type de compte de stockage :

Operation Type de compte de stockage Catégorie de facturation
Placer une liste de blocs Objet blob de blocs Premium
Standard v2 usage général
Standard v1 à usage général		 Opérations d’écriture

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

Voir également

Comprendre les blocs, les blocs d’ajout et les blocs de page
Autoriser les demandes adressées au stockage Azure
l’état et les codes d’erreur
Codes d’erreur du service blob
Définir des délais d’attente pour les opérations de service Blob

  • Last updated on