Blok van URL plaatsen
Met Put Block From URL
de bewerking maakt u een nieuw blok dat moet worden doorgevoerd als onderdeel van een blob waarin de inhoud wordt gelezen uit een URL. Deze API is beschikbaar vanaf versie 28-03-2018.
Aanvraag
U kunt de Put Block From URL
aanvraag als volgt samenstellen. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount door de naam van uw opslagaccount:
AANVRAAG-URI voor PUT-methode | HTTP-versie |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id |
HTTP/1.1 |
Aanvraag voor geëmuleerde opslagservice
Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de poort van de Blob-service 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?comp=block&blockid=id |
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
Parameter | Beschrijving |
---|---|
blockid |
Vereist. Een geldige Base64-tekenreekswaarde die het blok identificeert. Voordat de codering wordt uitgevoerd, moet de tekenreeks kleiner zijn dan of gelijk zijn aan 64 bytes. Voor een opgegeven blob moet de lengte van de opgegeven waarde voor de blockid parameter voor elk blok dezelfde grootte hebben.Opmerking: De Base64-tekenreeks moet URL-gecodeerd zijn. |
timeout |
Optioneel. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor blobservicebewerkingen voor meer informatie. |
Aanvraagheaders
De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:
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. Hiermee geeft u de versie van de bewerking te gebruiken voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-services voor meer informatie. Voor Put Block From URL moet de versie 28-03-2018 of hoger zijn. |
Content-Length |
Vereist. Hiermee geeft u het aantal bytes dat wordt verzonden in de aanvraagbody. De waarde van deze header moet worden ingesteld op 0. Wanneer de lengte niet 0 is, mislukt de bewerking met statuscode 400 (Ongeldige aanvraag). |
x-ms-copy-source:name |
Vereist. Hiermee geeft u de URL van de bron-blob op. 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 geautoriseerd via een handtekening voor gedeelde toegang. Als de bron-blob openbaar is, is er geen autorisatie vereist om de bewerking uit te voeren. 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 op. Zie Aanvragen autoriseren voor Azure Storage voor meer informatie. Alleen een bearer-schema wordt ondersteund voor Microsoft Entra. Deze header wordt ondersteund in versies 2020-10-02 en hoger. |
x-ms-source-range |
Optioneel. Uploadt alleen de bytes van de blob in de bron-URL in het opgegeven bereik. Als deze header niet is opgegeven, wordt de volledige inhoud van de bron-blob geüpload als één blok. Zie De bereikheader opgeven voor blobservicebewerkingen voor meer informatie. |
x-ms-source-content-md5 |
Optioneel. Een MD5-hash van de blokinhoud van de URI. Deze hash wordt gebruikt om de integriteit van het blok 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 copy-source met deze headerwaarde. Opmerking: deze MD5-hash wordt niet opgeslagen met de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (ongeldige aanvraag). |
x-ms-source-content-crc64 |
Optioneel. Een CRC64-hash van de blokinhoud van de URI. Deze hash wordt gebruikt om de integriteit van het blok 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 copy-source met deze headerwaarde. Opmerking: deze CRC64-hash wordt niet opgeslagen met de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (ongeldige aanvraag). Als zowel x-ms-source-content-md5 als x-ms-source-content-crc64 headers aanwezig zijn, mislukt de aanvraag met een 400 (Ongeldige aanvraag).Deze header wordt ondersteund in versies 2019-02-02 en hoger. |
x-ms-encryption-scope |
Optioneel. Geeft het versleutelingsbereik aan dat moet worden gebruikt om de broninhoud te versleutelen. Deze header wordt ondersteund in versies 2019-02-02 en hoger. |
x-ms-lease-id:<ID> |
Vereist als de blob een actieve lease heeft. Als u deze bewerking wilt uitvoeren op een blob met een actieve lease, geeft u de geldige lease-id voor deze header op. |
x-ms-client-request-id |
Optioneel. Biedt een door de client gegenereerde, ondoorzichtige waarde met een limiet van 1 kibibyte (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. Zie Azure Blob Storage bewaken voor meer informatie. |
Aanvraagheaders (door de klant verstrekte versleutelingssleutels)
Vanaf versie 2019-02-02 kunnen de volgende headers worden opgegeven in de aanvraag voor het versleutelen van een blob met een door de klant verstrekte sleutel. Versleuteling met een door de klant verstrekte sleutel (en de bijbehorende set headers) is optioneel.
Aanvraagheader | Beschrijving |
---|---|
x-ms-encryption-key |
Vereist. De met Base64 gecodeerde AES-256-versleutelingssleutel. |
x-ms-encryption-key-sha256 |
Vereist. De Base64-gecodeerde SHA256-hash van de versleutelingssleutel. |
x-ms-encryption-algorithm: AES256 |
Vereist. Hiermee geeft u het algoritme te gebruiken voor versleuteling. De waarde van deze header moet zijn AES256 . |
Aanvraagbody
Geen.
Voorbeeldaanvraag
Request Syntax:
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1
Request Headers:
x-ms-version: 2018-03-28
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499
Antwoord
Het antwoord bevat een HTTP-statuscode en een set antwoordheaders.
Statuscode
Een geslaagde bewerking retourneert statuscode 201 (gemaakt).
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 |
---|---|
Content-MD5 |
Geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. De waarde van deze header wordt berekend door Blob Storage. Dit is niet noodzakelijkerwijs hetzelfde als de waarde die is opgegeven in de aanvraagheaders. Voor versies 2019-02-02 en hoger wordt deze header alleen geretourneerd wanneer de aanvraag deze header heeft. |
x-ms-content-crc64 |
Voor versies 2019-02-02 en hoger. Geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. De waarde van deze header wordt berekend door Blob Storage. Dit is niet noodzakelijkerwijs hetzelfde als de waarde die is opgegeven in de aanvraagheaders. Wordt geretourneerd wanneer x-ms-source-content-md5 de header niet aanwezig is in de aanvraag. |
x-ms-request-id |
Identificeert op unieke wijze de aanvraag die is gedaan en u kunt deze gebruiken om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie. |
x-ms-version |
De Blob Storage-versie die is gebruikt om de aanvraag uit te voeren. |
Date |
Een UTC-datum/tijd-waarde die wordt gegenereerd door de service, die de tijd aangeeft waarop het antwoord is gestart. |
x-ms-request-server-encrypted: true/false |
Versie 2015-12-11 en hoger. De waarde van deze header wordt ingesteld op true als de inhoud van het blok is versleuteld met behulp van het opgegeven algoritme. Anders wordt de waarde ingesteld op false . |
x-ms-encryption-key-sha256 |
Versie 2019-02-02 en hoger. Wordt geretourneerd als de aanvraag een door de klant verstrekte sleutel gebruikt voor versleuteling, zodat de client ervoor kan zorgen dat de inhoud van de aanvraag is versleuteld met behulp van de opgegeven sleutel. |
x-ms-encryption-scope |
Versie 2019-02-02 en hoger. Wordt geretourneerd als de aanvraag een versleutelingsbereik heeft gebruikt, zodat de client ervoor kan zorgen dat de inhoud van de aanvraag is versleuteld met behulp van het versleutelingsbereik. |
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 niet meer dan 1024 zichtbare ASCII-tekens bevat. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze niet aanwezig in het antwoord. |
Voorbeeldantwoord
Response Status:
HTTP/1.1 201 Created
Response Headers:
Transfer-Encoding: chunked
x-ms-content-crc64: 77uWZTolTHU
Date: Sat, 31 Mar 2018 23:47:09 GMT
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
Autorisatie
Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Put Block From URL
bewerking autoriseren zoals hieronder wordt beschreven.
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 Put Block From URL
bewerking aan te roepen, en de ingebouwde Azure RBAC-rol met de minste bevoegdheden die deze actie omvat:
- Azure RBAC-actie:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
- Ingebouwde rol met minimale bevoegdheden:Inzender voor opslagblobgegevens
Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.
Opmerkingen
Put Block From URL
uploadt een blok voor toekomstige opname in een blok-blob. Een blok-blob kan maximaal 50.000 blokken bevatten. Elk blok kan een andere grootte hebben. De maximale grootte voor een blok dat wordt geüpload met Put Block From URL
is 100 mebibytes (MiB). Zie Put Block als u grotere blokken (maximaal 4000 MiB) wilt uploaden.
In versie 2020-10-02 en hoger wordt Microsoft Entra autorisatie ondersteund voor de bron van de kopieerbewerking.
Een blob kan op elk moment maximaal 100.000 niet-verzonden blokken hebben. Als dit maximum wordt overschreden, retourneert de service statuscode 409 (RequestEntityTooLargeBlockCountExceedsLimit).
In de volgende tabel worden de maximaal toegestane blok- en blobgrootten per serviceversie beschreven:
Serviceversie | Maximale blokgrootte (via Put Block From URL ) |
Maximale blobgrootte (via Put Block List ) |
Maximale blobgrootte via één schrijfbewerking (via Put Blob From URL ) |
---|---|---|---|
Versie 2020-04-08 en hoger | 4.000 MiB | Ongeveer 190,7 tebibytes (TiB) (4.000 MiB × 50.000 blokken) | 5.000 MiB |
Versies ouder dan 2020-04-08 | 100 MiB | Ongeveer 4,75 TiB (100 MiB × 50.000 blokken) | 256 MiB |
Nadat u een set blokken hebt geüpload, kunt u de blob op de server maken of bijwerken op basis van deze set door de bewerking Lijst met blokkeringen plaatsen aan te roepen. Elk blok in de set wordt geïdentificeerd door een blok-id die uniek is binnen die blob. Blok-id's zijn gericht op een bepaalde blob, zodat verschillende blobs blokken met dezelfde id's kunnen hebben.
Als u aanroept Put Block From URL
op een blob die nog niet bestaat, wordt er een nieuwe blok-blob gemaakt met een inhoudslengte van 0. Deze blob wordt geïnventariseerd door de List Blobs
bewerking als de include=uncommittedblobs
optie is opgegeven. Het blok of de blokken die u hebt geüpload, worden pas doorgevoerd als u de nieuwe blob aanroept Put Block List
. Een blob die op deze manier is gemaakt, wordt gedurende een week op de server onderhouden. Als u binnen die periode niet meer blokken of vastgelegde blokken aan de blob hebt toegevoegd, wordt de blob verwijderd.
Een blok dat is geüpload met de Put Block From URL
bewerking, wordt pas onderdeel van een blob nadat het is doorgevoerd met Put Block List
. Voordat Put Block List
wordt aangeroepen om de nieuwe of bijgewerkte blob door te voeren, retourneren aanroepen naar Blob ophalen de blobinhoud zonder dat het niet-doorgevoerde blok wordt opgenomen.
Als u een blok uploadt met dezelfde blok-id als een ander blok dat nog niet is doorgevoerd, wordt het laatste geüploade blok met die id doorgevoerd bij de volgende geslaagde Put Block List
bewerking.
Nadat Put Block List
is aangeroepen, worden alle niet-doorgevoerde blokken die zijn opgegeven in de bloklijst doorgevoerd als onderdeel van de nieuwe blob. Alle niet-doorgevoerde blokken die niet zijn opgegeven in de lijst met blokken voor de blob, worden verwijderd uit Blob Storage. Niet-doorgevoerde blokken worden ook verzameld als er binnen een week na de laatste geslaagde Put Block From URL
bewerking geen geslaagde aanroepen naar Put Block From URL
of Put Block List
op dezelfde blob zijn. Als Put Blob wordt aangeroepen op de blob, worden alle niet-doorgevoerde blokken garbage verzameld.
Als de blob een actieve lease heeft, moet de client een geldige lease-id opgeven voor de aanvraag om een blok naar de blob te schrijven. Als de client geen lease-id opgeeft of een ongeldige lease-id opgeeft, retourneert Blob Storage statuscode 412 (voorwaarde mislukt). Als de client een lease-id opgeeft, maar de blob geen actieve lease heeft, retourneert Blob Storage ook statuscode 412 (Voorwaarde mislukt).
Voor een opgegeven blob moeten alle blok-id's dezelfde lengte hebben. Als een blok wordt geüpload met een blok-id van een andere lengte dan die van de blok-id's voor bestaande niet-doorgevoerde blokken, retourneert de service foutcode 400 (Ongeldige aanvraag).
Als u aanroept Put Block From URL
, wordt de laatste wijzigingstijd van een bestaande blob niet bijgewerkt.
Als u op een pagina-blob aanroept Put Block From URL
, wordt een fout geretourneerd.
Het aanroepen Put Block From URL
van een archief-blob retourneert een fout en het aanroepen ervan op een hot
of-blob cool
verandert de bloblaag niet.
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 Put Block From URL
aanvragen op basis van het type opslagaccount:
Bewerking | Type opslagaccount | Factureringscategorie |
---|---|---|
Blokkeren van URL plaatsen (doelaccount1) | Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik |
Schrijfbewerkingen |
Blok van URL plaatsen (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.
Als de bron- en doelaccounts zich in verschillende regio's bevinden (bijvoorbeeld US - noord en VS - zuid), wordt de bandbreedte die wordt gebruikt voor het overdragen van de aanvraag als uitgaand verkeer in rekening gebracht bij het bronopslagaccount. Uitgaand verkeer tussen accounts binnen dezelfde regio is gratis.
Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorieën.