Blok plaatsen

Artikel
07/10/2024

Met Put Block de bewerking wordt een nieuw blok gemaakt dat moet worden doorgevoerd als onderdeel van een blob.

Aanvraag

U kunt de Put Block 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 deze wordt gecodeerd, moet de tekenreeks kleiner zijn dan of gelijk zijn aan 64 bytes. Voor een opgegeven blob moet de lengte van de 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.
`Content-Length`	Vereist. De lengte van de blokinhoud in bytes. Het blok moet kleiner zijn dan of gelijk zijn aan 4000 mebibytes (MiB) voor versie 2019-12-12 en hoger. Zie de sectie Opmerkingen voor limieten in oudere versies. Wanneer de lengte niet is opgegeven, mislukt de bewerking met de statuscode 411 (lengte vereist).
`Content-MD5`	Optioneel. Een MD5-hash van de blokinhoud. Deze hash wordt gebruikt om de integriteit van het blok tijdens het transport te controleren. Wanneer deze header is opgegeven, vergelijkt de opslagservice de hash van de inhoud die is aangekomen 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-content-crc64`	Optioneel. Een CRC64-hash van de blokinhoud. Deze hash wordt gebruikt om de integriteit van het blok tijdens het transport te controleren. Wanneer deze header is opgegeven, vergelijkt de opslagservice de hash van de inhoud die is aangekomen 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 Content-MD5- als x-ms-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 inhoud van de aanvraag 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

De aanvraagtekst 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

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 aanvullende 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 en is niet noodzakelijkerwijs dezelfde 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 wordt deze header geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. De waarde van deze header wordt berekend door Blob Storage en is niet noodzakelijkerwijs dezelfde waarde die is opgegeven in de aanvraagheaders. Deze header wordt geretourneerd wanneer `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`	Geeft de Blob Storage-versie aan die is gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gedaan op basis van versie 2009-09-19 of hoger.
`Date`	Een utc-datum/tijd-waarde die wordt gegenereerd door de service, die aangeeft wanneer 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 de aanvraag 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. Deze header wordt geretourneerd als de aanvraag een door de klant verstrekte sleutel heeft 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. Deze header 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 de 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: Sun, 25 Sep 2011 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 bewerking autoriseren zoals hieronder wordt beschreven.

Belangrijk

Microsoft raadt het gebruik van Microsoft Entra ID met beheerde identiteiten aan 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 voor het autoriseren van aanvragen voor blobgegevens. 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 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 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.

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, welke machtigingen ze hebben voor deze resources en hoe lang de SAS geldig is.

De Put Block bewerking ondersteunt drie typen handtekeningen voor gedeelde toegang: SAS voor gebruikersdelegatie, service-SAS en account-SAS.

Als best practice voor beveiliging raden we u aan Microsoft Entra-referenties te gebruiken in plaats van de opslagaccountsleutel, die 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 sleutel niet is toegestaan voor het opslagaccount, is een service-SAS-token of een ACCOUNT-SAS-token niet toegestaan op een aanvraag voor Blob Storage. Zie Begrijpen hoe het niet toewijzen van gedeelde sleutel van invloed is op SAS-tokens voor meer informatie.

SAS voor gebruikersdelegering

Een SAS voor gebruikersdelegatie wordt beveiligd met Microsoft Entra-referenties en ook door de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Put Block 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 Een SAS voor gebruikersdelegering maken voor meer informatie over de SAS voor gebruikersdelegatie.

Service-SAS

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

Voor het aanroepen van de Put Block bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blob-resource, is de machtiging Schrijven (w) vereist 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 gebruikersdelegatie-SAS zijn ook beschikbaar via een account-SAS.

In de volgende tabel ziet u het ondertekende resourcetype en de ondertekende machtigingen die moeten worden opgegeven bij het delegeren van toegang:

Bewerking	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blok plaatsen	Blob (b)	Object (o)	Schrijven (w)

Zie Een account-SAS maken voor meer informatie over de account-SAS.

Opmerkingen

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

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

Serviceversie	Maximale blokgrootte (via `Put Block`)	Maximale blobgrootte (via `Put Block List`)	Maximale blobgrootte via één schrijfbewerking (via `Put Blob`)
Versie 2019-12-12 en hoger	4.000 MiB	Ongeveer 190,7 tebibytes (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 ouder dan 31-05-2016	4 MiB	Ongeveer 195 gibibytes (GiB) (4 MiB × 50.000 blokken)	64 MiB

Het maximum aantal niet-doorgevoerde blokken dat aan een blob kan worden gekoppeld, is 100.000. Als dit aantal wordt overschreden, retourneert de service statuscode 409 (RequestEntityTooLargeBlockCountExceedsLimit).

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 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 uploadt, worden pas doorgevoerd als u de nieuwe blob aanroept Put Block List . Een blob die op deze manier wordt 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 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 lijst met blokkeringen doorgevoerd als onderdeel van de nieuwe blob. 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 bewerking geen geslaagde aanroepen naar Put Block 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 de blok-id's voor bestaande niet-doorgevoerde blokken, retourneert de service foutcode 400 (Ongeldige aanvraag).

Als u probeert een blok te uploaden dat groter is dan 4000 MiB voor versie 2019-12-12 of hoger, groter dan 100 MiB voor versie 2016-05-31 of hoger, of groter dan 4 MiB voor oudere versies, retourneert de service statuscode 413 (Aanvraagentiteit te groot). De service retourneert ook aanvullende informatie over de fout in het antwoord, waaronder de maximaal toegestane blokgrootte, in bytes.

Als u aanroept Put Block , wordt de laatste wijzigingstijd van een bestaande blob niet bijgewerkt.

Als u op een pagina-blob aanroept Put Block , wordt een fout geretourneerd.

Het aanroepen Put Block van een gearchiveerde 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 aanvragen op basis van het type opslagaccount:

Bewerking	Type opslagaccount	Factureringscategorie
Blok plaatsen	Premium-blok-blob Standard v2 voor algemeen gebruik Standard v1 voor algemeen gebruik	Schrijfbewerkingen¹

¹Put Block bewerkingen schrijven blokken naar tijdelijke opslag met behulp van de standaardtoegangslaag van het opslagaccount. Als u bijvoorbeeld een blob uploadt naar de archieflaag, worden bewerkingen Put Block die deel uitmaken van het uploaden in rekening gebracht als schrijfbewerkingen op basis van de standaardtoegangslaag van het opslagaccount, niet de doellaag. Put Block List en Put Blob bewerkingen worden echter in rekening gebracht als schrijfbewerkingen op basis van de doellaag van de blob.

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

Zie ook

Aanvragen voor Azure Storage autoriseren
Status en foutcodes
Foutcodes voor de Blob-service
Time-outs instellen voor blobservicebewerkingen

Delen via