Put Blob

Article
02/03/2024

L’opération Put Blob crée un objet blob de bloc, de page ou d’ajout, ou met à jour le contenu d’un objet blob de blocs existant. L’opération Put Blob remplacera tout le contenu d’un objet blob existant portant le même nom.

Lorsque vous mettez à jour un objet blob de blocs existant, vous remplacez toutes les métadonnées existantes sur l’objet blob. Le contenu de l’objet blob existant est remplacé par le contenu du nouvel objet blob. Les mises à jour partielles ne sont pas prises en charge avec Put Blob. Pour effectuer une mise à jour partielle du contenu d’un objet blob de blocs, utilisez l’opération Put Block List .

Vous pouvez créer un objet blob d’ajout dans les versions 2015-02-21 et ultérieures uniquement.

Un appel à un Put Blob pour créer un objet blob de pages ou un objet blob d’ajout initialise uniquement l’objet blob. Si l’objet blob existe déjà, le contenu est effacé. Pour ajouter du contenu à un objet blob de pages, appelez l’opération Put Page . Pour ajouter du contenu à un objet blob d’ajout, appelez l’opération Append Block .

Requête

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

URI de requête de méthode PUT	Version HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob`	HTTP/1.1

Demande de service de stockage émulée

Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et le port du service Blob en tant que 127.0.0.1:10000, suivis du nom du compte de stockage émulé :

URI de requête de méthode PUT	Version HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob`	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

Les paramètres supplémentaires suivants peuvent être spécifiés sur 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 (tous les types d’objets blob)

Les en-têtes de requête obligatoires et facultatifs pour tous les types d’objets blob 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. La longueur de la demande. Pour un objet blob de pages ou un objet blob d’ajout, la valeur de cet en-tête doit être définie sur zéro, car Put Blob est utilisé uniquement pour initialiser l’objet blob. Pour écrire du contenu dans un objet blob de pages existant, appelez Put Page. Pour écrire du contenu dans un objet blob d’ajout, appelez Append Block.
`Content-Type`	facultatif. Le type de contenu MIME de l'objet blob. Le type par défaut est `application/octet-stream`.
`Content-Encoding`	facultatif. Spécifie les codages de contenu qui ont été appliqués à l'objet blob. Cette valeur est retournée au client lorsque l’opération Obtenir l’objet blob est effectuée sur la ressource blob. Lorsque cette valeur est retournée, le client peut l’utiliser pour décoder le contenu de l’objet blob.
`Content-Language`	facultatif. Spécifie les langages naturels utilisés par cette ressource.
`Content-MD5`	facultatif. Un hachage MD5 du contenu de l'objet blob. Ce hachage est utilisé pour vérifier l'intégrité de l'objet blob pendant le transport. Lorsque cet en-tête est spécifié, le service de stockage vérifie le hachage qui est arrivé par rapport à celui qui a été envoyé. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte). Lorsque l’en-tête est omis dans la version 2012-02-12 ou ultérieure, le Stockage Blob génère un hachage MD5. Les résultats de Get Blob, Get Blob Properties et List Blobs incluent le hachage MD5.
`x-ms-content-crc64`	facultatif. Hachage CRC64 du contenu de l’objet blob. Ce hachage est utilisé pour vérifier l'intégrité de l'objet blob pendant le transport. Lorsque cet en-tête est spécifié, le service de stockage vérifie le hachage qui est arrivé par rapport à celui qui a été envoyé. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte). Cet en-tête est pris en charge dans les versions 02-02-2019 et ultérieures. Si les en-têtes Content-MD5 et x-ms-content-crc64 sont présents, la requête échoue avec une requête 400 (requête incorrecte).
`Cache-Control`	facultatif. Le Stockage Blob stocke cette valeur, mais ne l’utilise pas ou ne la modifie pas.
`x-ms-blob-content-type`	facultatif. Définit le type de contenu de l'objet blob.
`x-ms-blob-content-encoding`	facultatif. Définit l'encodage du contenu de l'objet blob.
`x-ms-blob-content-language`	facultatif. Définit la langue du contenu de l'objet blob.
`x-ms-blob-content-md5`	facultatif. Définit le hachage MD5 de l'objet blob. Pour BlockBlob, cet en-tête est prioritaire sur `Content-MD5` lors de la vérification de l’intégrité de l’objet blob pendant le transport. Pour PageBlob et AppendBlob, cet en-tête définit directement le hachage MD5 de l’objet blob.
`x-ms-blob-cache-control`	facultatif. Définit le contrôle du cache de l'objet blob.
`x-ms-blob-type: <BlockBlob ¦ PageBlob ¦ AppendBlob>`	Obligatoire. Spécifie le type d’objet blob à créer : objet blob de blocs, objet blob de pages ou objet blob d’ajout. La prise en charge de la création d’un objet blob d’ajout est disponible uniquement dans la version 2015-02-21 et ultérieure.
`x-ms-meta-name:value`	facultatif. Paires nom-valeur associées à l'objet blob en tant que métadonnées. Remarque : À compter 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 le contenu de la demande. Cet en-tête est pris en charge dans les versions 2019-02-02 et ultérieures.
`x-ms-encryption-context`	facultatif. La valeur par défaut est « Empty ». Si la valeur est définie, elle définit les métadonnées du système d’objets 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`	facultatif. Définit les balises encodées de chaîne de requête sur l’objet blob. Pour plus d’informations, consultez les remarques. Pris 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-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 `Content-Disposition` champ d’en-tête de réponse transmet des informations supplémentaires sur la façon de traiter la charge utile de réponse, et vous pouvez l’utiliser pour joindre des métadonnées supplémentaires. Par exemple, si l’en-tête est défini sur `attachment`, cela indique que l’agent utilisateur ne doit pas afficher la réponse. Au lieu de cela, il doit afficher une boîte de dialogue Enregistrer sous avec un nom de fichier autre que le nom d’objet blob spécifié. La réponse des opérations Get Blob et Get Blob Properties inclut l’en-tête `content-disposition` .
`Origin`	facultatif. Spécifie l'origine à partir de laquelle la demande est émise. La présence de cet en-tête entraîne des en-têtes de partage de ressources cross-origine (CORS) dans la réponse. Pour plus d’informations, consultez Prise en charge de CORS pour les services de stockage Azure.
`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 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 que le serveur reçoit. Pour plus d’informations, consultez À propos de la journalisation d’analytique du stockage.
`x-ms-access-tier`	facultatif. Niveau à définir sur l’objet blob. Pour les objets blob de pages sur un compte Stockage Premium uniquement avec la version 2017-04-17 et ultérieure. Pour obtenir la liste complète des niveaux pris en charge par les objets blob de pages, consultez Stockage Premium hautes performances et disques managés pour les machines virtuelles. Pour les objets blob de blocs, 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`. Avec `unlocked`, les utilisateurs peuvent modifier la stratégie en augmentant ou en diminuant la date de rétention jusqu’à. Avec `locked`, 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. Pour plus d’informations, 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é.

Cette opération prend également en charge l'utilisation d'en-têtes conditionnels pour écrire l'objet blob 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 (objets blob de pages uniquement)

Les en-têtes de requête qui s’appliquent uniquement aux opérations sur les objets blob de pages sont décrits dans le tableau suivant :

En-tête de requête	Description
`x-ms-blob-content-length: bytes`	Obligatoire pour les objets blob de pages. Cet en-tête spécifie la taille maximale de l’objet blob de pages, jusqu’à 8 tbioctets (Tio). La taille de l'objet blob de pages doit être alignée à une limite de 512 octets. Si cet en-tête est spécifié pour un objet blob de blocs ou un objet blob d’ajout, le Stockage Blob retourne status code 400 (Requête incorrecte).
`x-ms-blob-sequence-number: <num>`	facultatif. Défini uniquement pour les objets blob de pages. Le numéro de séquence est une valeur contrôlée par l'utilisateur que vous pouvez utiliser pour suivre les demandes. La valeur du numéro de séquence doit être comprise entre 0 et 2^{^63} - 1. La valeur par défaut est 0.
`x-ms-access-tier`	Version 2017-04-17 et ultérieures. Pour les objets blob de pages sur un compte de stockage Premium uniquement. Spécifie le niveau à définir sur l’objet blob. Pour obtenir la liste complète des niveaux pris en charge, consultez Stockage Premium hautes performances et disques managés pour machines virtuelles.
`x-ms-client-request-id`	Cet en-tête 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 demande, il ne sera pas présent dans la réponse.

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

À compter de la version 2019-02-02, les en-têtes suivants peuvent être spécifiés dans 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

Pour un objet blob de blocs, le corps de la demande contient le contenu de l'objet blob.

Pour un objet blob de pages ou un objet blob d’ajout, le corps de la demande est vide.

Exemple de requête

L'exemple suivant illustre une demande de création d'un objet blob de blocs :

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblockblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-content-disposition: attachment; filename="fname.ext"  
x-ms-blob-type: BlockBlob  
x-ms-meta-m1: v1  
x-ms-meta-m2: v2  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Content-Length: 11  
  
Request Body:  
hello world

Cet exemple de demande crée un objet blob de pages et spécifie sa taille maximale de 1 024 octets. Pour ajouter du contenu à un objet blob de pages, vous devez appeler Put Page :

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/mypageblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-type: PageBlob  
x-ms-blob-content-length: 1024  
x-ms-blob-sequence-number: 0  
Authorization: SharedKey   
Origin: http://contoso.com  
Vary: Origin  
myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Content-Length: 0

Cet exemple de demande crée un objet blob d’ajout. Pour ajouter du contenu à l’objet blob d’ajout, vous devez appeler Append Block :

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myappendblob HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
Content-Type: text/plain; charset=UTF-8  
x-ms-blob-type: AppendBlob  
Authorization: SharedKey myaccount:YhuFJjN4fAR8/AmBrqBz7MG2uFinQ4rkh4dscbj598g=  
Origin: http://contoso.com  
Vary: Origin  
Content-Length: 0

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 également inclure des en-têtes HTTP standard supplémentaires. Tous les en-têtes standard sont conformes à la spécification du protocole HTTP/1.1.

En-tête de réponse	Description
`ETag`	Contient une valeur que le client peut utiliser pour effectuer des opérations conditionnelles `PUT` à l’aide de l’en-tête de `If-Match` requête. 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/heure de la dernière modification de 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 d'écriture dans l'objet blob (notamment les mises à jour des métadonnées ou des propriétés de l'objet blob), modifie la heure de la dernière modification de l'objet blob.
`Content-MD5`	Retourné pour un objet blob de blocs afin que le client puisse case activée l’intégrité du contenu du message. La `Content-MD5` valeur retournée est calculée par Stockage Blob. Dans les versions 2012-02-12 et ultérieures, cet en-tête est retourné même lorsque la requête n’inclut pas d’en-têtes `Content-MD5` ou `x-ms-blob-content-md5` .
`x-ms-content-crc64`	Retourné pour un objet blob de blocs afin que le client puisse case activée l’intégrité du contenu du message. La `x-ms-content-crc64` valeur retournée est calculée par Stockage Blob. Cet en-tête est toujours retourné à partir de la version 2019-02-02.
`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 liés aux opérations d’API.
`x-ms-version`	Indique la version de Stockage Blob qui a été utilisée pour exécuter la demande. Retourné pour les demandes effectuées sur la version 2009-09-19 et ultérieure.
`Date`	Valeur de date/heure UTC générée par le service, qui indique l’heure à laquelle la réponse a été lancée.
`Access-Control-Allow-Origin`	Retourné si la demande inclut un en-tête `Origin` et le partage de ressources cross-origine (CORS) est activé avec une règle de correspondance. Cet en-tête retourne la valeur de l’en-tête de demande d’origine s’il existe une correspondance.
`Access-Control-Expose-Headers`	Retourné si la demande inclut un en-tête `Origin` et le partage de ressources cross-origine (CORS) est activé avec une règle de correspondance. Retourne la liste des en-têtes de réponse qui doivent être exposés au client ou à l'émetteur de la demande.
`Access-Control-Allow-Credentials`	Retourné si la requête inclut un `Origin` en-tête et que CORS est activé avec une règle de correspondance qui n’autorise pas toutes les origines. Cet en-tête a la valeur true.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 et ultérieures. La valeur de cet en-tête est définie `true` sur si le contenu de la requête est correctement chiffré à l’aide de l’algorithme spécifié. Sinon, la valeur est `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 et ultérieures. 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. 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 ultérieures. Cet en-tête 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 pour accéder à l’objet blob.

Response body

Aucun.

Exemple de réponse

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
Content-MD5: sQqNsWTgdUEFt6mb5y4/5Q==  
x-ms-content-crc64: 77uWZTolTHU
Date: <date>  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: <date>  
Access-Control-Allow-Origin: http://contoso.com  
Access-Control-Expose-Headers: Content-MD5  
Access-Control-Allow-Credentials: True  
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 Blob comme décrit ci-dessous.

Si une demande spécifie des balises avec l’en-tête x-ms-tags de requête, 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 dans le 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 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 Blob, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :

Action RBAC Azure :
- Create nouvel objet blob de blocs : Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
- Create nouvel objet blob de blocs ou remplacez-le : Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Rôle intégré avec privilèges minimum :Contributeur aux données Blob de stockage

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

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

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

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

Lorsque l’accès à la clé partagée n’est pas autorisé 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 en savoir plus, 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 signature d’accès partagé.

L’appel de l’opération à l’aide Put Blob d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation suivante dans le cadre du jeton SAP de délégation d’utilisateur :

Opération	Autorisation signée
Put Blob (créer un objet blob de blocs)	Create (c) ou Write (w)
Put Blob (remplacer l’objet blob de blocs existant)	Écriture (w)

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 de stockage Azure, tel que le stockage d’objets blob.

L’appel de l’opération à l’aide Put Blob d’un jeton SAP délégué à un conteneur ou à une ressource d’objet blob nécessite l’autorisation suivante dans le cadre du jeton SAP de service.

Opération	Autorisation signée
Put Blob (créer un objet blob de blocs)	Create (c) ou Write (w)
Put Blob (remplacer l’objet blob de blocs existant)	Écriture (w)

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 Blob (créer un objet blob de blocs)	Objet blob (b)	Objet (o)	Create (c) ou Écriture (w)
Put Blob (remplacer l’objet blob de blocs existant)	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 Blob 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

Lorsque vous créez un objet blob, vous devez spécifier s’il s’agit d’un objet blob de blocs, d’un objet blob d’ajout ou d’un objet blob de page en spécifiant la valeur de l’en-tête x-ms-blob-type . Une fois qu’un objet blob a été créé, le type de l’objet blob ne peut pas être modifié, sauf s’il est supprimé et recréé.

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 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

Si vous tentez de charger un objet blob de blocs supérieur à la taille maximale autorisée pour cette version de service ou un objet blob de pages supérieur à 8 Tio, le service retourne status code 413 (Demander une entité trop grande). Stockage Blob retourne également des informations supplémentaires sur l’erreur dans la réponse, y compris la taille maximale autorisée de l’objet blob, en octets.

Pour créer un objet blob de page, initialisez d’abord l’objet blob en appelant Put Blob, puis spécifiez sa taille maximale, jusqu’à 8 Tio. Lorsque vous créez un objet blob de page, n’incluez pas de contenu dans le corps de la demande. Une fois l’objet blob créé, appelez Put Page pour ajouter du contenu à l’objet blob ou le modifier.

Pour créer un objet blob d’ajout, appelez Put Blob pour le créer avec une longueur de contenu de 0 octet. Une fois l’objet blob d’ajout créé, appelez Append Block pour ajouter du contenu à la fin de celui-ci.

Si vous appelez Put Blob pour remplacer un objet blob existant portant le même nom, tous les instantanés associés à l’objet blob d’origine sont conservés. Pour supprimer les instantanés associés, appelez d’abord Supprimer l’objet blob, puis appelez Put Blob pour recréer l’objet blob.

Propriétés personnalisées d’objets blob

Un objet blob a des propriétés personnalisées (définies via des en-têtes) que vous pouvez utiliser pour stocker les valeurs associées aux en-têtes HTTP standard. Vous pouvez ensuite lire ces valeurs en appelant Get Blob Properties ou en les modifiant en appelant Set Blob Properties. Les en-têtes de propriété personnalisés et l'en-tête HTTP standard correspondant sont répertoriés dans le tableau suivant :

En-tête HTTP	En-tête de propriété personnalisé d'objet blob
`Content-Type`	`x-ms-blob-content-type`
`Content-Encoding`	`x-ms-blob-content-encoding`
`Content-Language`	`x-ms-blob-content-language`
`Content-MD5`	`x-ms-blob-content-md5`
`Cache-Control`	`x-ms-blob-cache-control`

La sémantique permettant de définir ou de conserver ces valeurs de propriété avec l’objet blob est la suivante :

Si le client spécifie un en-tête de propriété personnalisé, comme indiqué par le préfixe x-ms-blob, cette valeur est stockée avec l'objet blob.
Si le client spécifie un en-tête HTTP standard, mais pas l’en-tête de propriété personnalisée, la valeur est stockée dans la propriété personnalisée correspondante associée à l’objet blob et elle est retournée par un appel à Get Blob Properties. Par exemple, si le client définit l'en-tête Content-Type dans la demande, cette valeur est stockée dans la propriété x-ms-blob-content-type de l'objet blob.
Si le client définit à la fois l’en-tête HTTP standard et l’en-tête de propriété correspondant sur la même demande, la demande PUT utilise la valeur fournie pour l’en-tête HTTP standard, mais la valeur spécifiée pour l’en-tête de propriété personnalisé est conservée avec l’objet blob et retournée par les requêtes GET suivantes.

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 spécifiées dans Set Blob Tags. En outre, l’en-tête x-ms-tags peut contenir jusqu’à 2 Ko de balises. 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 remplacement de l’objet blob. 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 les versions 2013-08-15 et ultérieures. Pour les versions antérieures à 2013-08-15, Stockage Blob retourne status code 201 (Créé).

Si un objet blob existant avec un bail actif est remplacé par une Put Blob opération, le bail persiste sur l’objet blob mis à jour jusqu’à ce qu’il expire ou soit libéré.

Une Put Blob opération est autorisée à 10 minutes par Mio. Si l’opération prend plus de 10 minutes par Mio en moyenne, l’opération expire.

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

ExpiryOption

Vous pouvez envoyer les valeurs suivantes en tant qu’en-tête x-ms-expiry-option . Cet en-tête ne respecte pas la casse.

Option Expiration	Description
`RelativeToNow`	Définit la date d’expiration par rapport à l’heure actuelle. `x-ms-expiry-time` doit être spécifié comme le nombre de millisecondes à écouler à partir de l’heure actuelle.
`Absolute`	`x-ms-expiry-time` doit être spécifié en tant qu’heure absolue, au format RFC 1123.
`NeverExpire`	Définit l’objet blob pour qu’il n’expire jamais ou supprime la date d’expiration actuelle. `x-ms-expiry-time` ne doit pas être spécifié.

La sémantique permettant de définir une date d’expiration sur un objet blob est la suivante :

Set Expiry peut être défini uniquement sur un objet blob et non sur un répertoire.
Set Expiry avec un expiryTime dans le passé n’est pas autorisé.
ExpiryTimene peut pas être spécifié avec la expiryOption valeur .Never

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 Blob les demandes en fonction du type de compte de stockage :

Opération	Type de compte de stockage	Catégorie de facturation
Put Blob	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 tarification Stockage Blob Azure.

Voir aussi

Autoriser les demandes dans le 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