Zet blok

De Put Block operatie creëert een nieuw blok dat als onderdeel van een blob wordt toegewijd.

Aanvraag

U kunt de Put Block aanvraag als volgt samenstellen. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount door de naam van je opslagaccount:

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

Emulated storage-serviceaanvraag

Wanneer je een verzoek doet aan de geëmuleerde opslagservice, specificeer dan de hostnaam van de emulator en de poort van de Blob-service als 127.0.0.1:10000, gevolgd door de naam van het geëmuleerde opslagaccount:

PUT-methode request URI	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-ontwikkeling voor meer informatie.

URI Parameters

Kenmerk	Description
`blockid`	Verplicht. Een geldige Base64-tekenreekswaarde die het blok identificeert. Voordat het gecodeerd wordt, moet de string kleiner zijn dan of gelijk aan 64 bytes in grootte. Voor een gespecificeerde blob moet de lengte van de waarde voor de parameter voor elk `blockid` blok dezelfde grootte hebben. Opmerking: De Base64-string moet URL-gecodeerd zijn.
`timeout`	Optional. De `timeout` parameter wordt uitgedrukt in seconden. Voor meer informatie, zie Time-outs instellen voor Blob-serviceoperaties.

Headers aanvragen

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

Header van het verzoek	Description
`Authorization`	Verplicht. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening op. Zie Autorize requests to Azure Storage voor 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 verzoeken. Hiermee geeft u de versie van de bewerking die moet worden gebruikt voor deze aanvraag. Voor meer informatie, zie Versiebeheer voor de Azure Storage Services.
`Content-Length`	Verplicht. De lengte van de blokinhoud in bytes. Het blok moet kleiner zijn dan of gelijk aan 4.000 mebibyte (MiB) voor versie 2019-12-12 en later. Zie de sectie Opmerkingen voor limieten in oudere versies. Wanneer de lengte niet wordt opgegeven, mislukt de bewerking met de statuscode 411 (Vereiste Lengte).
`Content-MD5`	Optional. Een MD5-hash van de blokinhoud. Deze hash wordt gebruikt om de integriteit van het blok tijdens transport te verifiëren. Wanneer deze header wordt gespecificeerd, vergelijkt de opslagservice de hash van de inhoud die is aangekomen, met deze headerwaarde. Opmerking: Deze MD5-hash wordt niet opgeslagen bij de blob. Als de twee hashes niet overeenkomen, faalt de bewerking met foutcode 400 (Bad Request).
`x-ms-content-crc64`	Optional. Een CRC64-hash van de blokinhoud. Deze hash wordt gebruikt om de integriteit van het blok tijdens transport te verifiëren. Wanneer deze header wordt gespecificeerd, vergelijkt de opslagservice de hash van de inhoud die is aangekomen, met deze headerwaarde. Opmerking: Deze CRC64-hash wordt niet samen met de blob opgeslagen. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (Ongeldig verzoek). Als zowel Content-MD5 als x-ms-content-crc64 headers aanwezig zijn, faalt het verzoek met een 400 (Bad Request). Deze header wordt ondersteund in versies 2019-02-02 en later.
`x-ms-encryption-scope`	Optional. Geeft het versleutelingsbereik aan dat moet worden gebruikt om de inhoud van de aanvraag te versleutelen. Deze header wordt ondersteund in versies 2019-02-02 en later.
`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`	Optional. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie wordt 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.

Request-headers (door de klant verstrekte encryptiesleutels)

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

Header van het verzoek	Description
`x-ms-encryption-key`	Verplicht. De door Base64 gecodeerde AES-256 encryptiesleutel.
`x-ms-encryption-key-sha256`	Verplicht. De door Base64 gecodeerde SHA256-hash van de encryptiesleutel.
`x-ms-encryption-algorithm: AES256`	Verplicht. Specificeert het algoritme dat voor encryptie moet worden gebruikt. De waarde van deze header moet zijn `AES256`.

Verzoekheaders (gestructureerde body)

Vanaf versie 2025-01-05 kunnen de volgende headers op het verzoek worden gespecificeerd om gebruik te maken van het gestructureerde lichaamsformaat.

Header van het verzoek	Description
`Content-Length`	Verplicht. Moet de lengte van het gecodeerde verzoek zijn (niet alleen de lengte van de blokinhoud). Als de waarde van de header niet overeenkomt met de verwachte lengte van het gecodeerde verzoek, faalt de bewerking met foutcode 400 (Bad Request).
`x-ms-structured-body`	Verplicht. Moet worden opgenomen als het berichtformaat is gestructureerd. De waarde van deze header bevat de versie en eigenschappen van het berichtschema. Momenteel wordt alleen de waarde ondersteund , `XSM/1.0; properties=crc64`wat aangeeft dat het verzoek crc64-checksumsegmenten gebruikt in het gecodeerde bericht. Als de waarde hier niet overeenkomt, faalt de bewerking met foutcode 400 (Bad Request). Het verzoek zal ook falen als de inhoud die in het verzoek wordt geleverd niet overeenkomt met de opgegeven checksum voor een bepaald segment met foutcode 400 (Bad Request).
`x-ms-structured-content-length`	Verplicht. Moet worden opgenomen als het berichtformaat is gestructureerd. De waarde van deze header is de lengte van de blokinhoud en zal altijd kleiner zijn dan de `Content-Length` headerwaarde vanwege berichtcodering. Als de waarde van de header niet overeenkomt met de lengte van de blokinhoud die in het verzoek wordt gegeven, mislukt de operatie met foutcode 400 (Bad Request).

Inhoud van het verzoek

De verzoekbody bevat de inhoud van het blok.

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: 2011-08-18  
x-ms-date: Sun, 25 Sep 2011 14:37:35 GMT  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 1048576

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 koppen. Het antwoord kan ook aanvullende standaard HTTP-headers bevatten. Alle standaard headers voldoen aan de HTTP/1.1-protocolspecificatie.

Antwoordheader	Description
`Content-MD5`	Teruggegeven zodat de client kan controleren op de integriteit van de boodschapinhoud. De waarde van deze header wordt berekend door Blob Storage, en het is niet per se dezelfde waarde die in de request-headers wordt gespecificeerd. Voor versies 2019-02-02 en later wordt deze header alleen teruggegeven wanneer het verzoek deze header heeft.
`x-ms-content-crc64`	Voor versies 2019-02-02 en later wordt deze header teruggegeven zodat de client kan controleren op de integriteit van de berichtinhoud. De waarde van deze header wordt berekend door Blob Storage, en het is niet per se dezelfde waarde die in de request-headers wordt gespecificeerd. Deze header wordt teruggegeven wanneer `Content-md5` de header niet aanwezig is in het verzoek.
`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`	Geeft de Blob Storage-versie aan die werd gebruikt om het verzoek uit te voeren. Deze header wordt teruggegeven voor verzoeken die zijn ingediend tegen versie 2009-09-19 of later.
`Date`	Een UTC-datum/tijdwaarde die door de dienst wordt gegenereerd, die aangeeft wanneer de reactie is gestart.
`x-ms-request-server-encrypted: true/false`	Versie 2015-12-11 en later. De waarde van deze header wordt ingesteld op `true` als de inhoud van het verzoek succesvol is versleuteld met het opgegeven algoritme. Anders wordt de waarde gezet op `false`.
`x-ms-encryption-key-sha256`	Versie 2019-02-02 en later. Deze header wordt teruggegeven als het verzoek een door de klant verstrekte sleutel gebruikte voor versleuteling, zodat de client kan garanderen dat de inhoud van het verzoek succesvol wordt versleuteld door de geleverde sleutel te gebruiken.
`x-ms-encryption-scope`	Versie 2019-02-02 en later. Deze header wordt teruggegeven als het verzoek een encryptiescope gebruikte, zodat de client kan garanderen dat de inhoud van het verzoek succesvol wordt versleuteld door gebruik te maken van de encryptiescope.
`x-ms-client-request-id`	Kan worden gebruikt voor het oplossen van problemen met aanvragen en de bijbehorende antwoorden. 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.
`x-ms-structured-body`	Teruggestuurd als het verzoek als een gestructureerd body request is verwerkt. De waarde van deze header is gelijk aan de waarde die in het verzoek wordt verzonden, die momenteel moet zijn `XSM/1.0; properties=crc64`.

Voorbeeldantwoord

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Put Block 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.

Permissions

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Put Block-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 minste bevoegdheden:Storage Blob Data Contributor

Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor 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 met Microsoft Entra-referenties en ook met de machtigingen die zijn opgegeven voor de SAS.

Het aanroepen van de Put Block operatie met een SAS-token dat is gedelegeerd aan een container of blobresource vereist de Write (w)- toestemming als onderdeel van het gebruikersdelegatie-SAS-token.

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.

Het aanroepen van de Put Block operatie met een SAS-token dat is gedelegeerd aan een container of blobresource vereist de Write (w) -toestemming als onderdeel van het service-SAS-token.

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:

Operation	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Zet blok	Klodder (b)	Voorwerp (o)	Schrijf (w)

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

Opmerkingen

Put Block uploadt een blok voor toekomstige opname in een blokblob. Elk blok in een blok kan een andere grootte hebben. Een block blob kan maximaal 50.000 gecommitteerde blokken bevatten.

De volgende tabel beschrijft de maximaal toegestane blok- en blobgroottes, per serviceversie:

Serviceversie	Maximale blokgrootte (via `Put Block`)	Maximale blobgrootte (via `Put Block List`)	Maximale blobgrootte via een enkele schrijfoperatie (via `Put Blob`)
Versie 2019-12-12 en hoger	4.000 MiB	Ongeveer 190,7 tebibyte (TiB) (4.000 MiB × 50.000 blokken)	5.000 MiB
Versies 2016-05-31 tot en met 2019-07-07	100 MiB	Ongeveer 4,75 TiB (100 MiB × 50.000 blokken)	256 MiB
Versies van vóór 31-05-2016	4 MiB	Ongeveer 195 gibibyte (GiB) (4 MiB × 50.000 blokken)	64 MiB

Het maximale aantal niet-toegewijde blokken dat aan een blob kan worden gekoppeld is 100.000. Als dit aantal wordt overschreden, geeft de service statuscode 409 terug (RequestEntityTooLargeBlockCountExceedsLimit).

Nadat je een set blokken hebt geüpload, kun je de blob op de server aanmaken of updaten vanuit deze set door de Put Block List-operatie 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 beperkt tot een bepaalde blob, zodat verschillende blobs blokken met dezelfde ID's kunnen hebben.

Als je een blob oproept Put Block die nog niet bestaat, wordt er een nieuwe block blob aangemaakt met een inhoudslengte van 0. Deze blob wordt opgesomd door de List Blobs operatie als de include=uncommittedblobs optie is gespecificeerd. De blokken of blokken die je uploadt worden pas vastgelegd als je de nieuwe blob oproept Put Block List . Een blob die op deze manier wordt gemaakt, wordt een week lang op de server onderhouden. Als je binnen die periode geen extra blokken hebt toegevoegd of toegewijd aan de blob, wordt de blob garbage collected gehouden.

Een block dat succesvol met de Put Block operatie is geüpload, wordt pas onderdeel van een blob als het is gecommitteerd met Put Block List. Voordat Put Block List wordt aangeroepen om de nieuwe of bijgewerkte blob te commiten, geven alle aanroepen om Get Blob de inhoud van de blob terug zonder de niet-committed blok erbij te betrekken.

Als je een blokkade uploadt met dezelfde blok-ID als een andere blokkade die nog niet is gecommit, wordt de laatst geüploade blokkade met die ID gecommitteerd bij de volgende succesvolle Put Block List operatie.

Nadat Put Block List is aangeroepen, worden alle niet-gecommitteerde blokken die in de bloklijst zijn gespecificeerd als onderdeel van de nieuwe blob. Alle niet-toegewijde blokken die niet in de bloklijst voor de blob zijn gespecificeerd, worden garbage collected en verwijderd uit Blob Storage. Eventuele niet-committed blokken worden ook garbage collected als er binnen een week na de laatste succesvolle Put Block operatie geen succesvolle aanroepen naar Put Block of Put Block List op dezelfde blob zijn. Als Put Blob op de blob wordt aangeroepen, worden alle niet-committed blokken garbage collecte gemaakt.

Als de blob een actieve lease heeft, moet de client een geldige lease-ID op het verzoek opgeven om een blok naar de blob te schrijven. Als de client ofwel geen lease-ID specificeert of een ongeldige lease-ID opgeeft, geeft Blob Storage statuscode 412 (Precondition Failed) terug. Als de client een lease-ID specificeert maar de blob geen actieve lease heeft, geeft Blob Storage ook statuscode 412 (Precondition Failed) terug.

Voor een gespecificeerde blob moeten alle blok-ID's even lang zijn. Als een blok wordt geüpload met een blok-ID van een andere lengte dan de blok-ID's voor bestaande niet-committed blokken, geeft de service foutcode 400 (Bad Request) terug.

Als je probeert een blok te uploaden dat groter is dan 4.000 MiB voor versie 2019-12-12 of later, groter dan 100 MiB voor versie 2016-05-31 of later, of groter dan 4 MiB voor oudere versies, geeft de dienst statuscode 413 (Request Entity Too Large) terug. De service geeft ook aanvullende informatie terug over de fout in het antwoord, inclusief de maximaal toegestane blokgrootte, in bytes.

Callen Put Block werkt de laatst gewijzigde tijd van een bestaande blob niet bij.

Het aanroepen Put Block van een page blob geeft een foutmelding.

Het aanroepen Put Block van een gearchiveerde blob geeft een foutmelding, en het aanroepen ervan op een hot of cool blob verandert de blob-laag 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. Voor deze verzoeken worden kosten per transactie in rekening gebracht. Het type transactie is van invloed op de manier waarop de kosten in rekening worden gebracht op de rekening. Leestransacties worden bijvoorbeeld toegerekend aan een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor aanvragen op Put Block basis van het type opslagaccount:

Operation	Type opslagaccount	Facturering categorie
Zet blok	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Schrijfbewerkingen¹

¹Put Block Operaties schrijven blokken naar tijdelijke opslag met behulp van de standaard toegangslaag van het opslagaccount. Als je bijvoorbeeld een blob uploadt naar de archieflaag, worden alle Put Block bewerkingen die deel uitmaken van de upload als schrijfbewerkingen belast op basis van de standaard toegangslaag van het opslagaccount, niet de bestemmingslaag. Put Block List en Put Blob operaties worden echter als schrijfoperaties belast op basis van de bestemmingslag van de blob.

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

Zie ook

Aanvragen voor Azure Storage autoriseren
status en foutcodes
Blob service foutcodes
Stel time-outs in voor Blob-serviceoperaties

Last updated on 2026-01-22

Delen via