Copy Blob From URL
L’opération Copy Blob From URL copie un objet blob vers une destination dans le compte de stockage de manière synchrone pour des tailles d’objet blob source allant jusqu’à 256 miooctets (Mio). Cette API est disponible à partir de la version 2018-03-28.
La source d’une Copy Blob From URL opération peut être n’importe quel objet blob de blocs validé dans n’importe quel compte de stockage Azure qui est public ou autorisé avec une signature d’accès partagé.
Requête
Vous pouvez construire la Copy Blob From URL requête comme suit. Nous recommandons HTTPS. Remplacez myaccount par le nom de votre compte de stockage, mycontainer par le nom de votre conteneur et myblob par le nom de votre objet blob de destination.
| URI de requête de méthode PUT | Version HTTP |
|---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob |
HTTP/1.1 |
URI pour le service de stockage émulé
Lorsque vous effectuez une demande auprès du service de stockage émulé, spécifiez le nom d’hôte de l’émulateur et Stockage Blob Azure port comme 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 |
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’expiration pour les opérations de stockage Blob. |
En-têtes de requête
Le tableau suivant décrit les en-têtes de requête obligatoires et facultatifs :
| En-tête de requête | Description |
|---|---|
Authorization |
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. Pour plus d'informations, consultez la page Contrôle de version pour les services de Stockage Microsoft Azure. |
x-ms-meta-name:value |
facultatif. Spécifie une paire nom/valeur définie par l’utilisateur associée à l’objet blob. Si aucune paire nom/valeur n’est spécifiée, l’opération copie les métadonnées de l’objet blob ou du fichier source vers l’objet blob de destination. Si une ou plusieurs paires nom/valeur sont spécifiées, l’objet blob de destination est créé avec les métadonnées spécifiées et les métadonnées ne sont pas copiées à partir de l’objet blob ou du fichier source. À compter de la version 2009-09-19, les noms de métadonnées doivent respecter les règles de nommage des identificateurs C#. Pour plus d’informations, consultez Affectation de noms et référencement de conteneurs, d’objets blob et de métadonnées. |
x-ms-encryption-scope |
facultatif. Indique l’étendue de chiffrement pour le chiffrement du contenu de la demande. Cet en-tête est pris en charge dans la version 2020-12-06 et ultérieure. |
x-ms-tags |
facultatif. Définit des balises encodées sous forme de chaîne de requête sur l’objet blob. Les balises ne sont pas copiées à partir de la source de copie. Pour plus d’informations, consultez Remarques. Pris en charge dans la version 2019-12-12 et ultérieure. |
x-ms-copy-source-tag-option |
facultatif. Les valeurs possibles sont REPLACE et COPY (respect de la casse). La valeur par défaut est REPLACE.Si COPY est spécifié, les balises de l’objet blob source sont copiées dans l’objet blob de destination. L’objet blob source doit être privé et la demande doit avoir l’autorisation d’accéder à l’opération Obtenir des balises d’objet blob sur l’objet blob source et à l’opération Définir des balises d’objet blob sur l’objet blob de destination. Cela entraîne un appel supplémentaire à l’opération Get Blob Tags sur le compte source.REPLACE définit les balises que l’en-tête x-ms-tags spécifie sur l’objet blob de destination. Si x-ms-tags spécifie REPLACE et aucune balise, aucune balise n’est définie sur l’objet blob de destination. La spécification de COPY et x-ms-tags entraîne une erreur 409 (conflit).Pris en charge dans les versions 2021-04-10 et ultérieures. |
x-ms-source-if-modified-since |
facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob source a été modifié depuis la date/l'heure indiquées. Si l’objet blob source n’a pas été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure. |
x-ms-source-if-unmodified-since |
facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob source n'a pas été modifié depuis la date/l'heure indiquées. Si l’objet blob source a été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure. |
x-ms-source-if-match |
facultatif. Valeur ETag. Spécifiez cet en-tête conditionnel pour copier l’objet blob source uniquement si sa ETag valeur correspond à la valeur spécifiée. Si les valeurs ne correspondent pas, le Stockage Blob retourne status code 412 (échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure. |
x-ms-source-if-none-match |
facultatif. Valeur ETag. Spécifiez cet en-tête conditionnel pour copier l’objet blob uniquement si sa ETag valeur ne correspond pas à la valeur spécifiée. Si les valeurs sont identiques, le Stockage Blob retourne status code 412 (échec de la condition préalable). Vous ne pouvez pas spécifier cet en-tête si la source est un fichier Azure. |
If-Modified-Since |
facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob de destination a été modifié depuis la date/l'heure indiquées. Si l’objet blob de destination n’a pas été modifié, le Stockage Blob retourne status code 412 (Échec de la condition préalable). |
If-Unmodified-Since |
facultatif. Valeur DateTime. Spécifiez cet en-tête conditionnel pour copier l'objet blob uniquement si l'objet blob de destination n'a pas été modifié depuis la date/l'heure indiquées. Si l’objet blob de destination a été modifié, le Stockage Blob retourne status code 412 (échec de la condition préalable). |
If-Match |
facultatif. Valeur ETag. Spécifiez une ETag valeur pour cet en-tête conditionnel afin de copier l’objet blob uniquement si la valeur spécifiée ETag correspond à la ETag valeur d’un objet blob de destination existant. Si les valeurs ne correspondent pas, le Stockage Blob retourne status code 412 (échec de la condition préalable). |
If-None-Match |
facultatif. Valeur ETag ou caractère générique (*).Spécifiez une ETag valeur pour cet en-tête conditionnel afin de copier l’objet blob uniquement si la valeur spécifiée ETag ne correspond pas à la ETag valeur de l’objet blob de destination.Spécifiez le caractère générique (*) pour effectuer l’opération uniquement si l’objet blob de destination n’existe pas. Si la condition spécifiée n’est pas remplie, le Stockage Blob retourne status code 412 (Échec de la condition préalable). |
x-ms-copy-source:name |
Obligatoire. Spécifie l’URL de l’objet blob source. La valeur peut être une URL d’une longueur maximale de 2 Kibioctets (Kio) qui spécifie un objet blob. La valeur doit être encodée sous forme d'URL, comme dans une URI de demande. L’objet blob source doit être public ou autorisé via une signature d’accès partagé. Si l’objet blob source est public, aucune autorisation n’est requise pour effectuer l’opération. Si la taille de l’objet blob source est supérieure à 256 Mio, la requête échoue avec une erreur 409 (Conflit). Le type d’objet blob de l’objet blob source doit être l’objet blob de blocs. Voici quelques exemples d’URL d’objet source : - https://myaccount.blob.core.windows.net/mycontainer/myblob- https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>- https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime> |
x-ms-copy-source-authorization: <scheme> <signature> |
facultatif. Spécifie le schéma d’autorisation et la signature pour la source de copie. Pour plus d’informations, consultez Autoriser les requêtes auprès du Stockage Azure. Seul le porteur de schéma est pris en charge pour Microsoft Entra. Cet en-tête est pris en charge dans la version 2020-10-02 et ultérieure. |
x-ms-requires-sync:true |
Obligatoire. Indique qu’il s’agit d’une opération synchrone Copy Blob From URL au lieu d’une opération asynchrone Copy Blob . |
x-ms-source-content-md5 |
facultatif. Spécifie un hachage MD5 du contenu de l’objet blob à partir de l’URI. Ce hachage est utilisé pour vérifier l’intégrité de l’objet blob pendant le transport des données à partir de l’URI. Lorsque cet en-tête est spécifié, le service de stockage compare le hachage du contenu qui est arrivé de la source de copie avec cette valeur d’en-tête. Le hachage MD5 n’est pas stocké avec l’objet blob. Si les deux hachages ne correspondent pas, l'opération échoue avec le code d'erreur 400 (Demande incorrecte). |
x-ms-lease-id:<ID> |
Obligatoire si l'objet blob de destination a un bail actif. L'ID de bail spécifié pour cet en-tête doit correspondre à l'ID de bail de l'objet blob de destination. Si la demande n’inclut pas l’ID de bail ou s’il n’est pas valide, l’opération échoue avec status code 412 (échec de la condition préalable). Si cet en-tête est spécifié et que l’objet blob de destination n’a pas de bail actif, l’opération échoue avec status code 412 (échec de la condition préalable). Dans les versions 2012-02-12 et ultérieures, cette valeur doit spécifier un bail actif et infini pour un objet blob loué. Un ID de bail à durée finie échoue avec status code 412 (échec de la condition préalable). |
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 Kio enregistrée dans les journaux lors de la configuration de la journalisation. Nous vous recommandons vivement d’utiliser cet en-tête pour mettre en corrélation les activités côté client avec les demandes que le serveur reçoit. |
x-ms-access-tier |
facultatif. Spécifie le niveau à définir sur l’objet blob cible. Cet en-tête est destiné aux objets blob de pages sur un compte Premium uniquement avec la version 2017-04-17 et les versions ultérieures. Pour obtenir la liste complète des niveaux pris en charge, consultez Stockage Premium hautes performances et disques managés pour machines virtuelles. Cet en-tête est pris en charge sur la version 2018-11-09 et ultérieure pour les objets blob de blocs. La hiérarchisation d’objets blob de blocs est prise en charge sur les comptes Stockage Blob ou usage général v2. Les valeurs valides sont Hot, Cool, Cold et Archive.
Note: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. |
Corps de la demande
Aucun.
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 202 (Accepté).
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 |
Si la copie est terminée, contient la ETag valeur de l’objet blob de destination. Si la copie n’est pas terminée, contient la ETag valeur de l’objet blob vide créé au début de la copie.La ETag valeur est entre guillemets. |
Last-Modified |
Retourne la date/heure de fin de l’opération de copie dans l’objet blob de destination. |
x-ms-request-id |
Identifie de manière unique la demande qui a été effectuée. Vous pouvez l’utiliser pour résoudre les problèmes liés à 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 utilisée pour exécuter la requête. |
Date |
Valeur de date/heure UTC qui indique l’heure à laquelle le service a envoyé la réponse. |
x-ms-copy-id: <id> |
Identificateur de chaîne pour cette opération de copie. |
x-ms-copy-status: <success> |
Indique l’état de l’opération de copie. La valeur de success signifie que l’opération s’est terminée avec succès. |
x-ms-client-request-id |
Peut être utilisé pour résoudre les problèmes liés aux demandes et aux réponses correspondantes. La valeur de cet en-tête est égale à la valeur de l’en-tête x-ms-client-request-id , si elle est présente dans la requête et que la valeur est au maximum 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, cet en-tête ne sera pas présent dans la réponse. |
x-ms-request-server-encrypted: true/false |
Définissez sur true si le contenu de la requête est correctement chiffré via l’algorithme spécifié. Sinon, la valeur est false. |
x-ms-encryption-scope |
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é via l’étendue de chiffrement. |
Response body
Aucun.
Exemple de réponse
Voici un exemple de réponse pour une demande de copie d'un objet blob :
Response Status:
HTTP/1.1 202 Accepted
Response Headers:
Last-Modified: <date>
ETag: "0x8CEB669D794AFE2"
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: cc6b209a-b593-4be1-a38a-dde7c106f402
x-ms-version: 2018-03-28
x-ms-copy-id: 1f812371-a41d-49e6-b123-f4b542e851c5
x-ms-copy-status: success
Date: <date>
Autorisation
Une autorisation est requise lors de l’appel d’une opération d’accès aux données dans stockage Azure. Le tableau suivant décrit comment les objets de destination et source d’une Copy Blob From URL opération peuvent être autorisés :
| Type d’objet | autorisation Microsoft Entra ID | Autorisation signature d’accès partagé (SAP) | Autorisation de clé partagée (ou Shared Key Lite) |
|---|---|---|---|
| Objet blob de blocs de destination | Oui | Oui | Oui |
| Objet blob de blocs source dans le même compte de stockage | Oui | Oui | Oui |
| Objet blob de blocs source dans un autre compte de stockage | Non | Oui | Non |
Si une demande spécifie des balises dans l’en-tête x-ms-tags de la demande, l’appelant doit répondre aux exigences d’autorisation de l’opération Définir des balises blob .
Vous pouvez autoriser l’opération Copy Blob From URL comme décrit ci-dessous. Notez qu’un objet blob source dans un autre compte de stockage doit être autorisé séparément via le jeton SAS avec l’autorisation Lecture (r). Pour plus d’informations sur l’autorisation d’objet blob source, consultez les détails de l’en-tête x-ms-copy-sourcede requête .
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érationCopy Blob From URL, ainsi que le rôle RBAC Azure intégré le moins privilégié qui inclut cette action :
Objet blob de destination
- Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write (pour l’écriture dans un objet blob existant) ou Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action (pour écrire un nouvel objet blob dans la destination)
- Rôle intégré le moins privilégié :Contributeur aux données blob de stockage
Objet blob source dans le même compte de stockage
- Action RBAC Azure :Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
- Rôle intégré le moins privilégié :Lecteur de 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.
Remarques
L’objet blob source et de destination d’une Copy Blob From URL opération doit être un objet blob de blocs.
Dans les versions 2020-10-02 et ultérieures, l’autorisation Microsoft Entra est prise en charge pour la source de l’opération de copie.
L’opération Copy Blob From URL copie toujours l’intégralité du blob source. La copie d’une plage d’octets ou d’un ensemble de blocs n’est pas prise en charge.
Vous pouvez copier un objet blob source dans un objet blob de destination dont le nom est différent. L’objet blob de destination peut être un objet blob de blocs existant ou un nouvel objet blob créé par l’opération de copie.
Lorsque vous copiez à partir d’un objet blob de blocs, tous les blocs validés et leurs ID de bloc sont copiés. Les blocs non validés ne sont pas copiés. À la fin de l’opération de copie, l’objet blob de destination aura le même nombre de blocs validés que la source.
La ETag valeur d’un objet blob de blocs change au démarrage de l’opération Copy Blob From URL et à la fin de l’opération.
Copie des métadonnées et des propriétés d’objet blob
Lorsqu’un objet blob de blocs est copié, les propriétés système suivantes sont copiées dans l’objet blob de destination avec les mêmes valeurs :
Content-TypeContent-EncodingContent-LanguageContent-LengthCache-ControlContent-MD5Content-Disposition
La liste de blocs validée de l’objet blob source est également copiée dans l’objet blob de destination. Les blocs non validés ne sont pas copiés.
L’objet blob de destination a toujours la même taille que l’objet blob source, de sorte que la valeur de l’en-tête Content-Length de l’objet blob de destination correspond à la valeur de cet en-tête pour l’objet blob source.
Si l’en-tête x-ms-tags fournit des balises pour l’objet blob de destination, 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 l’opération Définir des balises blob .
L’en-tête x-ms-tags peut contenir jusqu’à 2 kilobits de balises. Si vous avez besoin d’autres balises, utilisez l’opération Set Blob Tags .
Si l’en-tête x-ms-tags ne fournit pas d’étiquettes, les balises ne sont pas copiées à partir de l’objet blob source.
Copie d’un objet blob loué
L’opération Copy Blob From URL lit uniquement à partir de l’objet blob source, de sorte que l’état de bail de l’objet blob source n’a pas d’importance.
Facturation
Les demandes de tarification peuvent provenir de clients qui utilisent les API Stockage Blob, soit directement via l’API REST Stockage Blob, soit à 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 d’écriture. Le tableau suivant montre la catégorie de facturation pour Copy Blob From URL les demandes en fonction du type de compte de stockage :
| Opération | Type de compte de stockage | Catégorie de facturation |
|---|---|---|
| Copier l’objet blob à partir de l’URL (comptede destination 1) | Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard |
Opérations d’écriture |
| Copier l’objet blob à partir de l’URL (compte source2) | Objet blob de blocs Premium Usage général v2 Standard Usage général v1 standard |
Lire les opérations |
1Le compte de destination est facturé pour une transaction pour lancer l’écriture.
2Le compte source implique une transaction pour chaque demande de lecture à l’objet source.
Pour en savoir plus sur la tarification pour les catégories de facturation spécifiées, consultez tarification Stockage Blob Azure.
En outre, si les comptes source et de destination résident dans différentes régions (par exemple, USA Nord et USA Sud), la bande passante que vous utilisez pour transférer la demande est facturée au compte de stockage source en tant que sortie. Les sorties entre les comptes au sein de la même région sont gratuits.
Lorsque vous copiez un objet blob source vers un objet blob de destination dont le nom est différent au sein du même compte, vous utilisez des ressources de stockage supplémentaires pour le nouvel objet blob. L’opération de copie entraîne ensuite des frais sur l’utilisation de la capacité du compte de stockage pour ces ressources supplémentaires.
Voir aussi
Autoriser les demandes dans le Stockage Azure
Codes d’état et d’erreur
Codes d’erreur stockage Blob
Comprendre comment les instantanés accumulent les frais