Blok van URL plaatsen

2025-05-11

Met deze Put Block From URL bewerking wordt een nieuw blok gemaakt dat moet worden vastgelegd als onderdeel van een blob waarbij de inhoud wordt gelezen van een URL. Deze API is beschikbaar vanaf versie 2018-03-28.

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:

PUT methode URI aanvragen	HTTP-versie
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

Emulated storage-serviceaanvraag

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

PUT methode URI aanvragen	HTTP-versie
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

Zie De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkelingvoor meer informatie.

URI Parameters

Kenmerk	Beschrijving
`blockid`	Verplicht. Een geldige Base64-tekenreekswaarde die het blok identificeert. Vóór codering 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 even groot zijn. Opmerking: De Base64-tekenreeks moet URL-gecodeerd zijn.
`timeout`	Facultatief. De parameter `timeout` wordt uitgedrukt in seconden. Zie Time-outs instellen voor blobservicebewerkingenvoor meer informatie.

Headers aanvragen

De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:

Header van het verzoek	Beschrijving
`Authorization`	Verplicht. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
`Date` of `x-ms-date`	Verplicht. Hiermee geeft u de Coordinated Universal Time (UTC) voor de aanvraag. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie.
`x-ms-version`	Vereist voor alle geautoriseerde aanvragen. Hiermee geeft u de versie van de bewerking die moet worden gebruikt voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-servicesvoor meer informatie. Voor `Put Block From URL`moet de versie 28-03-2018 of later zijn.
`Content-Length`	Verplicht. Hiermee geeft u het aantal bytes dat wordt verzonden in de aanvraagbody. De waarde van deze kop moet op 0 zijn gezet. Als de lengte niet 0 is, mislukt de bewerking met statuscode 400 (Ongeldig verzoek).
`x-ms-copy-source:name`	Verplicht. Hiermee geeft u de URL van de bron-blob op. De waarde kan een URL zijn van maximaal 2 kibibyte (KiB) lang 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 URL's voor bronobjecten: - `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>`	Facultatief. Hiermee geeft u het autorisatieschema en de handtekening voor de kopieerbron. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie. Opmerking: Alleen een regeling aan toonder wordt ondersteund voor Microsoft Entra. Opmerking: Als uw bronobject openbaar toegankelijk is of als uw bronobject zich in een opslagaccount bevindt en u een SAS-token gebruikt dat wordt doorgegeven `x-ms-copy-source:name`, is deze header niet nodig. Deze header wordt ondersteund in versies 2020-10-02 en hoger.
`x-ms-source-range`	Facultatief. Uploadt alleen de bytes van de blob in de bron-URL in het opgegeven bereik. Als deze koptekst niet is opgegeven, wordt de volledige inhoud van de bron-blob geüpload als één blok. Zie De bereikheader opgeven voor Blob-servicebewerkingen voor meer informatie.
`x-ms-source-content-md5`	Facultatief. Een MD5-hash van de blokinhoud van de URI. Deze hash wordt gebruikt om de integriteit van het blok te verifiëren 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 (Ongeldig verzoek).
`x-ms-source-content-crc64`	Facultatief. Een CRC64-hash van de blokinhoud van de URI. Deze hash wordt gebruikt om de integriteit van het blok te verifiëren 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 (Ongeldig verzoek). Als zowel als `x-ms-source-content-md5x-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`	Facultatief. 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`	Facultatief. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet 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.
`x-ms-file-request-intent`	Vereist als `x-ms-copy-source` de header een Azure-bestands-URL is en `x-ms-copy-source-authorization` de header een OAuth-token opgeeft. Acceptabele waarde is `backup`. Deze header geeft aan dat de `Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action` of `Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action` moeten worden verleend als ze zijn opgenomen in het RBAC-beleid dat is toegewezen aan de identiteit die is geautoriseerd met behulp van de `x-ms-copy-source-authorization`-header. Beschikbaar voor versie 2025-07-05 en later.

Aanvraagheaders (door de klant verstrekte coderingssleutels)

Vanaf versie 2019-02-02 kunnen de volgende headers worden gespecificeerd voor de aanvraag om een blob te versleutelen met een door de klant opgegeven sleutel. Versleuteling met een door de klant verstrekte sleutel (en de bijbehorende set headers) is optioneel.

Header van het verzoek	Beschrijving
`x-ms-encryption-key`	Verplicht. De met Base64 gecodeerde AES-256-versleutelingssleutel.
`x-ms-encryption-key-sha256`	Verplicht. De met Base64 gecodeerde SHA256-hash van de versleutelingssleutel.
`x-ms-encryption-algorithm: AES256`	Verplicht. Hiermee geeft u het algoritme op dat moet worden gebruikt voor versleuteling. De waarde van deze header moet zijn `AES256`.

Inhoud van het verzoek

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

Reactie

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

Statuscode

Een geslaagde bewerking retourneert statuscode 201 (gemaakt).

Zie Status en foutcodesvoor meer informatie over statuscodes.

Antwoordkopteksten

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

Antwoordheader	Beschrijving
`Content-MD5`	Geretourneerd zodat de client kan controleren op integriteit van berichtinhoud. 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 bevat.
`x-ms-content-crc64`	Voor versies 2019-02-02 en later. Geretourneerd zodat de client kan controleren op integriteit van berichtinhoud. De waarde van deze header wordt berekend door Blob Storage. Het 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`	Identificeer de aanvraag die is gedaan en u kunt deze gebruiken om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossenvoor meer informatie.
`x-ms-version`	De Blob Storage-versie die is gebruikt om de aanvraag uit te voeren.
`Date`	Een UTC-datum/tijdwaarde die wordt gegenereerd door de service, wat de tijd aangeeft waarop het antwoord is gestart.
`x-ms-request-server-encrypted: true/false`	Versie 2015-12-11 en later. De waarde van deze header is ingesteld op `true` als de inhoud van het blok is versleuteld met behulp van het opgegeven algoritme. Anders is de waarde ingesteld op `false`.
`x-ms-encryption-key-sha256`	Versie 2019-02-02 en hoger. Geretourneerd als voor de aanvraag een door de klant verstrekte sleutel voor versleuteling is gebruikt, zodat de client ervoor kan zorgen dat de inhoud van de aanvraag wordt versleuteld met behulp van de opgegeven sleutel.
`x-ms-encryption-scope`	Versie 2019-02-02 en hoger. Geretourneerd als voor de aanvraag een versleutelingsbereik is gebruikt, zodat de client ervoor kan zorgen dat de inhoud van de aanvraag wordt 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 om 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.

Microsoft Entra-id (aanbevolen)
Sas- (Shared Access Signatures)
gedeelde sleutel

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 beveiligingsprincipaal. De beveiligingsprincipaal kan een door een gebruiker, groep, toepassingsservice-principal of door Azure beheerde identiteit zijn. De beveiligingsprincipaal wordt geverifieerd door Microsoft Entra ID om een OAuth 2.0-token terug te geven. Het token kan vervolgens worden gebruikt om een aanvraag te autoriseren voor de Blob-service.

Zie Toegang tot blobs autoriseren met behulp van Microsoft Entra IDvoor 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 minst bevoorrechte ingebouwde Azure RBAC-rol 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 blobgegevensvoor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Een Shared Access Signature (SAS) biedt beveiligde gedelegeerde toegang tot resources in een opslagaccount. Met een SAS hebt u gedetailleerde controle over hoe een client toegang heeft tot gegevens. U kunt opgeven tot welke resource de client toegang heeft, tot welke machtigingen deze resources beschikken en hoe lang de SAS geldig is.

De bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: SAS-voor gebruikersdelegering, SAS-van service en SAS--account-.

Het is raadzaam om microsoft Entra-referenties te gebruiken in plaats van de sleutel van het opslagaccount, wat gemakkelijker kan worden aangetast. Als voor uw toepassingsontwerp handtekeningen voor gedeelde toegang zijn vereist, gebruikt u Microsoft Entra-referenties om, indien mogelijk, een SAS voor gebruikersdelegatie te maken.

Wanneer toegang tot gedeelde sleutels niet is toegestaan voor het opslagaccount, is een SAS-token van de service of een SAS-accounttoken niet toegestaan bij een aanvraag naar Blob Storage. Zie Begrijpen hoe de toewijzing van gedeelde sleutels van invloed is op SAS-tokensvoor meer informatie.

Gebruikersdelegatie SAS

Een SAS voor gebruikersdelegering wordt beveiligd door middel van Microsoft Entra-referenties en door de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Put Block From URL-bewerking met behulp van een SAS-token dat is gedelegeerd aan een container- of blobresource, is de machtiging Schrijven (w) vereist als onderdeel van het SAS-token voor gebruikersdelegatie.

Zie Sas voor gebruikersdelegering makenvoor meer informatie over de SAS voor gebruikersdelegering.

Service-SAS

Een service-SAS wordt beveiligd met de sleutel van het opslagaccount. Een service-SAS delegeert de toegang tot een resource in één Azure Storage-service, zoals blobopslag.

Zie Een service-SAS-maken voor meer informatie over de SERVICE-SAS.

Account-SAS

Een account-SAS wordt beveiligd met de sleutel van het opslagaccount. Een account-SAS delegeert toegang tot resources in een of meer van de opslagservices. Alle bewerkingen die beschikbaar zijn via een service of gebruikersdelegering-SAS, zijn ook beschikbaar via een account-SAS.

De volgende tabel geeft het ondertekende resourcetype en de ondertekende machtigingen aan die moeten worden opgegeven bij het delegeren van toegang:

Operatie	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blok van URL plaatsen	Klodder (b)	Voorwerp (o)	Schrijven (w)

Zie Een SAS-account makenvoor meer informatie over de ACCOUNT-SAS.

Opmerkingen

Put Block From URL Uploadt een blok voor toekomstige opname in een blokblob. Een blok-blob kan maximaal 50.000 blokken bevatten. Elk blok kan een andere grootte hebben. De maximale grootte voor een blok waarmee wordt geüpload Put Block From URL is 100 mebibyte (MiB). Zie Blok plaatsen om grotere blokken (tot 4.000 MiB) te 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-vastgelegde blokken bevatten. Als dit maximum wordt overschreden, retourneert de service statuscode 409 (RequestEntityTooLargeBlockCountExceedsLimit).

In de volgende tabel worden de maximaal toegestane blok- en blobgroottes per serviceversie beschreven:

Serviceversie	Maximale blokgrootte (via `Put Block From URL`)	Maximale blobgrootte (via `Put Block List`)	Maximale blobgrootte via enkele schrijfbewerking (via `Put Blob From URL`)
Versie 2020-04-08 en later	4.000 miljoen	Ongeveer 190,7 tebibyte (TiB) (4.000 MiB × 50.000 blokken)	5.000 MiB
Versies eerder 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 Blokkeerlijst 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 een blob aanroept Put Block From URL die nog niet bestaat, wordt er een nieuwe blokblob 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 vastgelegd als u de nieuwe blob aanroept Put Block List . Een blob die op deze manier is gemaakt, wordt een week lang op de server bewaard. Als u binnen die periode niet meer blokken hebt toegevoegd of blokken aan de blob hebt vastgelegd, wordt de blob verzameld afval.

Een blok dat met de Put Block From URL bewerking is geüpload, wordt pas onderdeel van een blob als het is vastgelegd met Put Block List. Voordat Put Block List wordt aangeroepen om de nieuwe of bijgewerkte blob vast te leggen, retourneren aanroepen naar Get Blob de blobinhoud zonder de opname van het niet-vastgelegde blok.

Als u een blok uploadt dat dezelfde blok-ID heeft als een ander blok dat nog niet is vastgelegd, wordt het laatst geüploade blok met die ID vastgelegd bij de volgende succesvolle Put Block List bewerking.

Nadat Put Block List is aangeroepen, worden alle niet-vastgelegde blokken die in de blokkeerlijst zijn opgegeven, vastgelegd als onderdeel van de nieuwe blob. Alle niet-vastgelegde blokken die niet zijn opgegeven in de blokkeerlijst voor de blob, worden verzameld en verwijderd uit Blob Storage. Niet-vastgelegde blokken worden ook verzameld als er binnen een week na de laatste geslaagde Put Block From URL bewerking geen succesvolle aanroepen naar Put Block List of Put Block From URL op dezelfde blob zijn. Als Put Blob op de blob wordt aangeroepen, worden alle niet-vastgelegde blokken verzameld met afval.

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 (Voorvoorwaarde mislukt). Als de client een lease-id opgeeft, maar de blob geen actieve lease heeft, retourneert Blob Storage ook statuscode 412 (Voorvoorwaarde mislukt).

Voor een opgegeven blob moeten alle blok-ID's even lang zijn. Als een blok wordt geüpload met een blok-ID van een andere lengte dan die van de blok-ID's voor bestaande niet-vastgelegde blokken, retourneert de service foutresponscode 400 (Bad Request).

Aanroepen Put Block From URL werkt de laatst gewijzigde tijd van een bestaande blob niet bij.

Als u een pagina-blob aanroept Put Block From URL , wordt er een fout geretourneerd.

Als u een archief-blob aanroept Put Block From URL , wordt er een fout geretourneerd en als u deze aanroept op een hot of cool blob, wordt de bloblaag niet gewijzigd.

Facturatie

Prijsaanvragen kunnen afkomstig zijn van clients die Blob Storage-API's gebruiken, rechtstreeks via de Blob Storage REST API of vanuit een Azure Storage-clientbibliotheek. Deze aanvragen maken kosten per transactie. Het type transactie is van invloed op de manier waarop het account in rekening wordt gebracht. Leestransacties worden bijvoorbeeld opgebouwd tot 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:

Operatie	Type opslagaccount	Factureringscategorie
Zet Blokkeren van URL (bestemmingsaccount¹)	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Schrijfbewerkingen
Blok van URL plaatsen (bronaccount²)	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Leesbewerkingen

¹Het bestemmingsaccount wordt in rekening gebracht voor één transactie om het schrijven te starten.
^{Arabisch cijfer}Het bronaccount voert één transactie uit voor elke leesaanvraag naar het bronobject.

Als de bron- en doelaccounts zich in verschillende regio's bevinden (bijvoorbeeld VS - noord en VS - zuid), wordt de bandbreedte die wordt gebruikt voor het overbrengen van de aanvraag in rekening gebracht op het bronopslagaccount als uitgaand bestanddeel. Uitgaand verkeer tussen accounts binnen dezelfde regio is gratis.

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

Delen via