Share via


Blob kopiëren van URL

Met Copy Blob From URL de bewerking wordt een blob synchroon gekopieerd naar een doel binnen het opslagaccount voor bronblobgrootten van maximaal 256 mebibytes (MiB). Deze API is beschikbaar vanaf versie 28-03-2018.

De bron voor een Copy Blob From URL bewerking kan elke vastgelegde blok-blob zijn in elk Azure-opslagaccount dat openbaar is of is geautoriseerd met een handtekening voor gedeelde toegang.

Aanvraag

U kunt de Copy Blob From URL aanvraag als volgt samenstellen. We raden HTTPS aan. Vervang myaccount door de naam van uw opslagaccount, mycontainer door de naam van uw container en myblob door de naam van uw doel-blob.

AANVRAAG-URI voor PUT-methode HTTP-versie
https://myaccount.blob.core.windows.net/mycontainer/myblob HTTP/1.1

URI voor de geëmuleerde opslagservice

Wanneer u een aanvraag voor de geëmuleerde opslagservice indient, geeft u de hostnaam van de emulator en Azure Blob Storage poort op als 127.0.0.1:10000, gevolgd door de naam van het geëmuleerde opslagaccount:

AANVRAAG-URI voor PUT-methode HTTP-versie
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob HTTP/1.1

Zie Use the Azurite emulator for local Azure Storage development (De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkeling) voor meer informatie.

URI-parameters

U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:

Parameter Beschrijving
timeout Optioneel. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie.

Aanvraagheaders

In de volgende tabel worden vereiste en optionele aanvraagheaders beschreven:

Aanvraagheader Beschrijving
Authorization Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen autoriseren voor Azure Storage voor meer informatie.
Date of x-ms-date Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storage voor meer informatie.
x-ms-version Vereist voor alle geautoriseerde aanvragen. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
x-ms-meta-name:value Optioneel. Hiermee geeft u een door de gebruiker gedefinieerd naam/waardepaar op dat is gekoppeld aan de blob. Als er geen naam-waardeparen zijn opgegeven, worden de metagegevens van de bron-blob of het bronbestand naar de doel-blob gekopieerd. Als een of meer naam-/waardeparen zijn opgegeven, wordt de doel-blob gemaakt met de opgegeven metagegevens en worden metagegevens niet gekopieerd uit de bron-blob of het bronbestand.

Vanaf versie 2009-09-19 moeten namen van metagegevens voldoen aan de naamgevingsregels voor C#-id's. Zie Containers, blobs en metagegevens een naam geven en hiernaar verwijzen voor meer informatie.
x-ms-encryption-scope Optioneel. Geeft het versleutelingsbereik aan voor het versleutelen van de inhoud van de aanvraag. Deze header wordt ondersteund in versie 2020-12-06 en hoger.
x-ms-tags Optioneel. Hiermee stelt u tags met queryreekscodering in op de blob. Tags worden niet gekopieerd uit de kopieerbron. Zie Opmerkingen voor meer informatie. Ondersteund in versie 2019-12-12 en hoger.
x-ms-copy-source-tag-option Optioneel. Mogelijke waarden zijn REPLACE en COPY (hoofdlettergevoelig). De standaardwaarde is REPLACE.

Als COPY is opgegeven, worden de tags van de bron-blob gekopieerd naar de doel-blob. De bron-blob moet privé zijn en de aanvraag moet gemachtigd zijn voor de bewerking Blobtags ophalen op de bron-blob en de bewerking Blobtags instellen op de doel-blob. Hierdoor wordt de bewerking voor het Get Blob Tags bronaccount extra aangeroepen.

REPLACE hiermee stelt u tags in die in de x-ms-tags header worden opgegeven op de doel-blob. Als x-ms-tags u en geen tags opgeeft REPLACE , worden er geen tags ingesteld op de doel-blob. Het opgeven van COPY en x-ms-tags resulteert in een 409-fout (conflict).

Ondersteund in versie 2021-04-10 en hoger.
x-ms-source-if-modified-since Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de bron-blob is gewijzigd sinds de opgegeven datum/tijd. Als de bron-blob niet is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is.
x-ms-source-if-unmodified-since Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de bron-blob niet is gewijzigd sinds de opgegeven datum/tijd. Als de bron-blob is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is.
x-ms-source-if-match Optioneel. Een ETag waarde. Geef deze voorwaardelijke header op om de bron-blob alleen te kopiëren als ETag de waarde overeenkomt met de opgegeven waarde. Als de waarden niet overeenkomen, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is.
x-ms-source-if-none-match Optioneel. Een ETag waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de ETag waarde niet overeenkomt met de opgegeven waarde. Als de waarden identiek zijn, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt). U kunt deze header niet opgeven als de bron een Azure-bestand is.
If-Modified-Since Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de doel-blob is gewijzigd sinds de opgegeven datum/tijd. Als de doel-blob niet is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt).
If-Unmodified-Since Optioneel. Een DateTime waarde. Geef deze voorwaardelijke header op om de blob alleen te kopiëren als de doel-blob niet is gewijzigd sinds de opgegeven datum/tijd. Als de doel-blob is gewijzigd, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt).
If-Match Optioneel. Een ETag waarde. Geef een ETag waarde op voor deze voorwaardelijke header om de blob alleen te kopiëren als de opgegeven ETag waarde overeenkomt met de ETag waarde voor een bestaande doel-blob. Als de waarden niet overeenkomen, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt).
If-None-Match Optioneel. Een ETag waarde of het jokerteken (*).

Geef een ETag waarde op voor deze voorwaardelijke header om de blob alleen te kopiëren als de opgegeven ETag waarde niet overeenkomt met de ETag waarde voor de doel-blob.

Geef het jokerteken (*) op om de bewerking alleen uit te voeren als de doel-blob niet bestaat.

Als niet aan de opgegeven voorwaarde wordt voldaan, retourneert Blob Storage statuscode 412 (voorwaarde mislukt).
x-ms-copy-source:name Vereist. Hiermee geeft u de URL van de bron-blob. De waarde kan een URL van maximaal 2 kibibytes (KiB) zijn die een blob aangeeft. De waarde moet URL-gecodeerd zijn zoals deze wordt weergegeven in een aanvraag-URI. De bron-blob moet openbaar zijn of zijn geautoriseerd via een shared access signature. Als de bron-blob openbaar is, is er geen autorisatie vereist om de bewerking uit te voeren. Als de grootte van de bron-blob groter is dan 256 MiB, mislukt de aanvraag met een 409-fout (conflict). Het blobtype van de bron-blob moet blok-blob zijn. Hier volgen enkele voorbeelden van bronobject-URL's:

- 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> Optioneel. Hiermee geeft u het autorisatieschema en de handtekening voor de kopieerbron. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie.
Alleen de regelingsdrager wordt ondersteund voor Microsoft Entra.
Deze header wordt ondersteund in versie 2020-10-02 en hoger.
x-ms-requires-sync:true Vereist. Geeft aan dat dit een synchrone Copy Blob From URL bewerking is in plaats van een asynchrone Copy Blob bewerking.
x-ms-source-content-md5 Optioneel. Hiermee geeft u een MD5-hash van de blob-inhoud van de URI. Deze hash wordt gebruikt om de integriteit van de blob te controleren tijdens het transport van de gegevens uit de URI. Wanneer deze header is opgegeven, vergelijkt de opslagservice de hash van de inhoud die afkomstig is van de kopieerbron met deze headerwaarde.

De MD5-hash wordt niet opgeslagen met de blob.

Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (Ongeldige aanvraag).
x-ms-lease-id:<ID> Vereist als de doel-blob een actieve lease heeft. De lease-id die voor deze header is opgegeven, moet overeenkomen met de lease-id van de doel-blob. Als de aanvraag de lease-id niet bevat of niet geldig is, mislukt de bewerking met statuscode 412 (voorwaarde mislukt).

Als deze header is opgegeven en de doel-blob momenteel geen actieve lease heeft, mislukt de bewerking met statuscode 412 (voorwaarde mislukt).

In versie 2012-02-12 en hoger moet deze waarde een actieve, oneindige lease voor een geleasede blob opgeven. Een lease-id met een eindige duur mislukt met statuscode 412 (voorwaarde mislukt).
x-ms-client-request-id Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 KiB die wordt vastgelegd in de logboeken wanneer logboekregistratie is geconfigureerd. We raden u ten zeerste aan deze header te gebruiken om activiteiten aan de clientzijde te correleren met aanvragen die de server ontvangt.
x-ms-access-tier Optioneel. Hiermee geeft u de laag moet worden ingesteld op de doel-blob. Deze header is alleen voor pagina-blobs op een Premium-account met versie 2017-04-17 en hoger. Zie Premium Storage met hoge prestaties en beheerde schijven voor VM's voor een volledige lijst met ondersteunde lagen. Deze header wordt ondersteund op versie 2018-11-09 en hoger voor blok-blobs. Blok-blob-lagen worden ondersteund in Blob Storage- of Algemeen v2-accounts. Geldige waarden zijn Hot, Cool, Cold en Archive. Opmerking:Cold laag wordt ondersteund voor versie 2021-12-02 en hoger. Zie Dynamische, statische en archiefopslaglagen voor gedetailleerde informatie over opslaglagen voor blokblobs.

Aanvraagbody

Geen.

Antwoord

Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.

Statuscode

Een geslaagde bewerking retourneert statuscode 202 (Geaccepteerd).

Zie Status- en foutcodes voor meer informatie over statuscodes.

Antwoordheaders

Het antwoord voor deze bewerking bevat de volgende headers. Het antwoord kan ook extra standaard-HTTP-headers bevatten. Alle standaardheaders voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader Description
ETag Als de kopie is voltooid, bevat de ETag waarde van de doel-blob. Als het kopiëren niet is voltooid, bevat deze de ETag waarde van de lege blob die aan het begin van de kopie is gemaakt.

De ETag waarde staat tussen aanhalingstekens.
Last-Modified Retourneert de datum/tijd waarop de kopieerbewerking naar de doel-blob is voltooid.
x-ms-request-id Uniek identificeert de aanvraag die is gedaan. U kunt deze gebruiken om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie.
x-ms-version Geeft de versie van Blob Storage aan die wordt gebruikt om de aanvraag uit te voeren.
Date Een UTC-datum/tijd-waarde die de tijd aangeeft waarop de service het antwoord heeft verzonden.
x-ms-copy-id: <id> Tekenreeks-id voor deze kopieerbewerking.
x-ms-copy-status: <success> Geeft de status van de kopieerbewerking aan. Een waarde van success betekent dat de bewerking is voltooid.
x-ms-client-request-id Kan worden gebruikt om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header, als deze aanwezig is in de aanvraag en de waarde maximaal 1024 zichtbare ASCII-tekens is. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze header niet aanwezig in het antwoord.
x-ms-request-server-encrypted: true/false Stel in op true als de inhoud van de aanvraag is versleuteld via het opgegeven algoritme. Anders is falsede waarde .
x-ms-encryption-scope Wordt geretourneerd als de aanvraag een versleutelingsbereik gebruikt, zodat de client ervoor kan zorgen dat de inhoud van de aanvraag is versleuteld via het versleutelingsbereik.

Hoofdtekst van de reactie

Geen.

Voorbeeldantwoord

Hier volgt een voorbeeldantwoord voor een aanvraag voor het kopiëren van een 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>  
  

Autorisatie

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. In de volgende tabel wordt beschreven hoe de doel- en bronobjecten voor een Copy Blob From URL bewerking kunnen worden geautoriseerd:

Objecttype Microsoft Entra ID autorisatie SAS-autorisatie (Shared Access Signature) Autorisatie van gedeelde sleutels (of Shared Key Lite)
Doelblok-blob Ja Ja Ja
Bronblok-blob in hetzelfde opslagaccount Ja Ja Ja
Bronblok-blob in een ander opslagaccount Nee Ja Nee

Als een aanvraag tags opgeeft in de x-ms-tags aanvraagheader, moet de aanroeper voldoen aan de autorisatievereisten van de bewerking Blobtags instellen .

U kunt de Copy Blob From URL bewerking autoriseren zoals hieronder wordt beschreven. Houd er rekening mee dat een bron-blob in een ander opslagaccount afzonderlijk moet worden geautoriseerd via een SAS-token met de machtiging Lezen (r). Zie de details voor de aanvraagheader voor meer informatie over bron-blob-autorisatie x-ms-copy-source.

Belangrijk

Microsoft raadt aan Microsoft Entra ID met beheerde identiteiten te gebruiken om aanvragen voor Azure Storage te autoriseren. Microsoft Entra ID biedt superieure beveiliging en gebruiksgemak in vergelijking met autorisatie van gedeelde sleutels.

Azure Storage ondersteunt het gebruik van Microsoft Entra ID om aanvragen voor blobgegevens te autoriseren. Met Microsoft Entra ID kunt u op rollen gebaseerd toegangsbeheer van Azure (Azure RBAC) gebruiken om machtigingen te verlenen aan een beveiligingsprincipal. De beveiligingsprincipal kan een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token te retourneren. Het token kan vervolgens worden gebruikt om een aanvraag voor de Blob-service te autoriseren.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra ID voor meer informatie over autorisatie met behulp van Microsoft Entra ID.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra gebruiker, groep, beheerde identiteit of service-principal om de Copy Blob From URL bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:

Doel-blob

Bron-blob binnen hetzelfde opslagaccount

Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Opmerkingen

De bron- en doel-blob voor een Copy Blob From URL bewerking moeten een blok-blob zijn.

In versie 2020-10-02 en hoger wordt Microsoft Entra autorisatie ondersteund voor de bron van de kopieerbewerking.

Met de Copy Blob From URL bewerking wordt altijd de hele bron-blob gekopieerd. Het kopiëren van een bereik van bytes of een set blokken wordt niet ondersteund.

U kunt een bron-blob kopiëren naar een doel-blob met een andere naam. De doel-blob kan een bestaande blok-blob zijn of een nieuwe blob die door de kopieerbewerking wordt gemaakt.

Wanneer u kopieert vanuit een blok-blob, worden alle vastgelegde blokken en de bijbehorende blok-id's gekopieerd. Niet-doorgevoerde blokken worden niet gekopieerd. Aan het einde van de kopieerbewerking heeft de doel-blob hetzelfde aantal vastgelegde blokken als de bron.

De ETag waarde voor een blok-blob wordt gewijzigd wanneer de Copy Blob From URL bewerking wordt gestart en wanneer de bewerking is voltooid.

Blob-eigenschappen en metagegevens kopiëren

Wanneer een blok-blob wordt gekopieerd, worden de volgende systeemeigenschappen met dezelfde waarden gekopieerd naar de doel-blob:

  • Content-Type

  • Content-Encoding

  • Content-Language

  • Content-Length

  • Cache-Control

  • Content-MD5

  • Content-Disposition

De lijst met vastgelegde blokkeringen van de bron-blob wordt ook gekopieerd naar de doel-blob. Eventuele niet-doorgevoerde blokken worden niet gekopieerd.

De doel-blob is altijd even groot als de bron-blob, zodat de waarde van de Content-Length header voor de doel-blob overeenkomt met de waarde van die header voor de bron-blob.

Als de x-ms-tags header tags voor de doel-blob bevat, moeten deze worden gecodeerd met queryreeksen. Tagsleutels en -waarden moeten voldoen aan de naamgevings- en lengtevereisten die zijn opgegeven in de bewerking Blobtags instellen .

De x-ms-tags header kan maximaal 2 kilobits tags bevatten. Als u meer tags nodig hebt, gebruikt u de Set Blob Tags bewerking.

Als de x-ms-tags header geen tags bevat, worden tags niet gekopieerd uit de bron-blob.

Een geleasede blob kopiëren

De Copy Blob From URL bewerking leest alleen uit de bron-blob, dus de leasestatus van de bron-blob is niet van belang.

Billing

Prijsaanvragen kunnen afkomstig zijn van clients die gebruikmaken van Blob Storage-API's, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Met deze aanvragen worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de rekening in rekening wordt gebracht. Leestransacties worden bijvoorbeeld toegevoegd aan een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Copy Blob From URL aanvragen op basis van het type opslagaccount:

Bewerking Type opslagaccount Factureringscategorie
Blob kopiëren van URL (doelaccount1) Premium-blok-blob
Standard v2 voor algemeen gebruik
Standard v1 voor algemeen gebruik
Schrijfbewerkingen
Blob kopiëren van URL (bronaccount2) Premium-blok-blob
Standard v2 voor algemeen gebruik
Standard v1 voor algemeen gebruik
Leesbewerkingen

1Het doelaccount wordt in rekening gebracht voor één transactie om de schrijfbewerking te initiëren.
2Het bronaccount maakt één transactie voor elke leesaanvraag naar het bronobject.

Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorieën.

Als de bron- en doelaccounts zich in verschillende regio's bevinden (bijvoorbeeld VS - noord en VS - zuid), wordt de bandbreedte die u gebruikt om de aanvraag over te dragen, in rekening gebracht bij het bronopslagaccount als uitgaand verkeer. Uitgaand verkeer tussen accounts binnen dezelfde regio is gratis.

Wanneer u een bron-blob kopieert naar een doel-blob met een andere naam binnen hetzelfde account, gebruikt u extra opslagresources voor de nieuwe blob. De kopieerbewerking resulteert vervolgens in kosten ten opzichte van het capaciteitsgebruik van het opslagaccount voor deze extra resources.

Zie ook

Aanvragen voor Azure Storage autoriseren
Status en foutcodes
Blob Storage-foutcodes
Inzicht in hoe momentopnamen kosten genereren