Abort Copy Blob

L’opération Abort Copy Blob annule une opération en attente Copy Blob et laisse un objet blob de destination avec aucune longueur et des métadonnées complètes. Cette opération s’applique à la version 2012-02-12 et ultérieure.

Requête

Construisez l’opération Abort Copy Blob comme suit. HTTPS est recommandé. 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. Remplacez par <id> l’identificateur de copie fourni dans l’en-tête x-ms-copy-id de l’opération d’origine Copy Blob .

À compter de la version 2013-08-15, vous pouvez spécifier une signature d’accès partagé pour l’objet blob de destination s’il se trouve dans le même compte que l’objet blob source. À compter de la version 2015-04-05, vous pouvez également spécifier une signature d’accès partagé pour l’objet blob de destination s’il se trouve dans un autre compte de stockage.

URI de demande de méthode PUT Version HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=copy&copyid=<id> HTTP/1.1

URI de service de stockage émulé

Lorsque vous effectuez une demande auprès du service de stockage local, spécifiez le nom d’hôte local et Stockage Blob Azure port comme 127.0.0.1:10000, suivi du nom du compte de stockage local :

URI de demande de méthode PUT Version HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=copy&copyid=<id> 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 le paramètre supplémentaire suivant sur l’URI de 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’expiration pour les opérations de stockage 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 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-lease-id:<ID> Obligatoire si l'objet blob de destination a un bail infini actif.
x-ms-copy-action: abort Obligatoire.
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 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 reçues par le serveur. Pour plus d’informations, consultez Surveiller Stockage Blob Azure.

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 204 (Aucun contenu). Pour plus d’informations sur les codes status, consultez État et codes 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
x-ms-request-id Cet en-tête identifie de manière unique la demande qui a été effectuée et peut être utilisé pour la résolution des problèmes de la demande. Pour plus d’informations, consultez Résolution des problèmes liés aux opérations d’API.
x-ms-version Indique la version du stockage Blob utilisée pour exécuter la demande.
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-client-request-id Vous pouvez utiliser cet en-tête pour résoudre les demandes et les 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 demande. La valeur est, au maximum, 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 n’est pas présent dans la réponse.

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 Abort Copy Blob comme décrit ci-dessous.

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érationAbort Copy Blob, ainsi que 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 l’accès aux données d’objets blob.

Remarques

Lorsque vous annulez une opération en attente Copy Blob , l’en-tête de l’objet blob de x-ms-copy-status destination est défini sur aborted. L’annulation d’une opération de copie entraîne la création d’un objet blob de destination de longueur nulle pour les objets blob de blocs, les objets blob d’ajout et les objets blob de pages. Toutefois, les métadonnées de l’objet blob de destination auront les nouvelles valeurs copiées à partir de l’objet blob source ou définies explicitement dans l’appel d’opération Copy Blob . Pour conserver les métadonnées d'origine avant la copie, effectuez un instantané de l'objet blob de destination avant d'appeler Copy Blob.

Vous ne pouvez annuler qu’une opération de copie en attente. La tentative d’annulation d’une copie terminée ou ayant échoué entraîne une erreur de conflit. La tentative d’annulation d’une opération de copie à l’aide d’un ID de copie incorrect génère également une erreur de conflit.

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

Opération Type de compte de stockage Catégorie de facturation
Abort Copy Blob Objet blob de blocs Premium
Usage général v2 Standard
Autres opérations
Abort Copy Blob 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 Stockage Blob Azure
Opération copier l’objet blob