Lijst met blokkeringen plaatsen

Artikel
02/03/2024

Met Put Block List de bewerking wordt een blob geschreven door de lijst met blok-id's op te geven waaruit de blob bestaat. Als u wilt worden geschreven als onderdeel van een blob, moet een blok naar de server zijn geschreven in een eerdere Put Block-bewerking .

U kunt aanroepen Put Block List om een blob bij te werken door alleen de blokken te uploaden die zijn gewijzigd en vervolgens de nieuwe en bestaande blokken samen door te voeren. U kunt dit doen door op te geven of een blok moet worden doorgevoerd vanuit de lijst met vastgelegde blokkeringen of vanuit de lijst met niet-doorgevoerde blokkeringen, of door de laatst geüploade versie van het blok door te voeren, ongeacht de lijst waartoe deze behoort.

Aanvraag

U kunt de Put Block List 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=blocklist`	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=blocklist`	HTTP/1.1

De opslagemulator ondersteunt alleen blobgrootten van maximaal 2 gibibytes (GiB).

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 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 aanvraaginhoud, in bytes. Deze koptekst verwijst naar de inhoudslengte van de lijst met blokken, niet naar de blob zelf.
`Content-MD5`	Optioneel. Een MD5-hash van de aanvraaginhoud. Deze hash wordt gebruikt om de integriteit van de aanvraaginhoud tijdens het transport te controleren. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (ongeldige aanvraag). Deze header is gekoppeld aan de aanvraaginhoud en niet aan de inhoud van de blob zelf.
`x-ms-content-crc64`	Optioneel. Een CRC64-hash van de aanvraaginhoud. Deze hash wordt gebruikt om de integriteit van de aanvraaginhoud tijdens het transport te controleren. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (ongeldige aanvraag). Deze header is gekoppeld aan de aanvraaginhoud en niet aan de inhoud van de blob zelf. 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 versie 2019-02-02 en hoger.
`x-ms-blob-cache-control`	Optioneel. Hiermee stelt u het cachebeheer van de blob in. Als deze eigenschap is opgegeven, wordt deze opgeslagen met de blob en geretourneerd met een leesaanvraag. Als de eigenschap niet is opgegeven bij de aanvraag, wordt deze gewist voor de blob als de aanvraag is geslaagd.
`x-ms-blob-content-type`	Optioneel. Hiermee stelt u het inhoudstype van de blob in. Als deze is opgegeven, wordt deze eigenschap opgeslagen met de blob en geretourneerd met een leesaanvraag. Als het inhoudstype niet is opgegeven, wordt het ingesteld op het standaardtype, namelijk `application/octet-stream`.
`x-ms-blob-content-encoding`	Optioneel. Hiermee stelt u de inhoudscodering van de blob in. Als deze is opgegeven, wordt deze eigenschap opgeslagen met de blob en geretourneerd met een leesaanvraag. Als de eigenschap niet is opgegeven bij de aanvraag, wordt deze gewist voor de blob als de aanvraag is geslaagd.
`x-ms-blob-content-language`	Optioneel. Hiermee stelt u de inhoudstaal van de blob in. Als deze is opgegeven, wordt deze eigenschap opgeslagen met de blob en geretourneerd met een leesaanvraag. Als de eigenschap niet is opgegeven bij de aanvraag, wordt deze gewist voor de blob als de aanvraag is geslaagd.
`x-ms-blob-content-md5`	Optioneel. Een MD5-hash van de blobinhoud. Deze hash is niet gevalideerd, omdat de hashes voor de afzonderlijke blokken zijn gevalideerd toen ze werden geüpload. De bewerking Blob ophalen retourneert de waarde van deze header in de content-MD5-antwoordheader. Als deze eigenschap niet is opgegeven bij de aanvraag, wordt deze gewist voor de blob als de aanvraag is geslaagd.
`x-ms-meta-name:value`	Optioneel. Door de gebruiker gedefinieerde naam-waardeparen die zijn gekoppeld aan de blob. Vanaf versie 2009-09-19 moeten namen van metagegevens voldoen aan de naamgevingsregels voor C#-id's.
`x-ms-encryption-scope`	Optioneel. Geeft het versleutelingsbereik aan dat moet worden gebruikt om de blob te versleutelen. Deze waarde moet overeenkomen met het versleutelingsbereik dat wordt gebruikt voor het versleutelen van alle blokken die worden doorgevoerd. Deze header wordt ondersteund in versie 2019-02-02 en hoger.
`x-ms-encryption-context`	Optioneel. De standaardwaarde is Leeg. Als de waarde is ingesteld, worden de metagegevens van het blobsysteem ingesteld. Maximale lengte-1024. Alleen geldig wanneer hiërarchische naamruimte is ingeschakeld voor het account. Deze header wordt ondersteund in versies 2021-08-06 en hoger.
`x-ms-tags`	Optioneel. Hiermee stelt u de opgegeven met querytekenreeks gecodeerde tags op de blob in. Zie de sectie Opmerkingen voor meer informatie. Ondersteund in versie 2019-12-12 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 analyselogboeken wanneer logboekregistratie voor opslaganalyse 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-blob-content-disposition`	Optioneel. Hiermee stelt u de koptekst van `Content-Disposition` de blob in. Beschikbaar voor versie 2013-08-15 en hoger. Het `Content-Disposition` veld header bevat aanvullende informatie over het verwerken van de nettolading van het antwoord en kan worden gebruikt om aanvullende metagegevens toe te voegen. Als deze bijvoorbeeld is ingesteld op `attachment`, geeft deze koptekst aan dat de user-agent het antwoord niet moet weergeven, maar in plaats daarvan een dialoogvenster Opslaan als moet weergeven. Het antwoord van de bewerkingen Blob ophalen en Eigenschappen van blob ophalen bevat de header voor het verwijderen van inhoud.
`x-ms-access-tier`	Optioneel. Versie 2018-11-09 en hoger. Geeft de laag aan die moet worden ingesteld voor een blob. Voor blok-blobs wordt deze header alleen ondersteund in blobopslag- of v2-accounts voor algemeen gebruik met versie 2018-11-09 en hoger. Geldige waarden voor blok-bloblagen 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.
`x-ms-immutability-policy-until-date`	Versie 2020-06-12 en hoger. Hiermee geeft u de retentie-tot-datum die moet worden ingesteld voor de blob. Dit is de datum totdat de blob kan worden beveiligd tegen wijzigen of verwijderen. Volgt RFC1123 indeling.
`x-ms-immutability-policy-mode`	Versie 2020-06-12 en hoger. Hiermee geeft u de beleidsmodus voor onveranderbaarheid op die moet worden ingesteld voor de blob. Geldige waarden zijn `unlocked` en `locked`. De `unlocked` waarde geeft aan dat gebruikers het beleid kunnen wijzigen door de bewaardatum te verhogen of te verlagen. De `locked` waarde geeft aan dat deze acties verboden zijn.
`x-ms-legal-hold`	Versie 2020-06-12 en hoger. Hiermee geeft u de juridische bewaring moet worden ingesteld voor de blob. De geldige waarden zijn `true` en `false`.
`x-ms-expiry-option`	Optioneel. Versie 2023-08-03 en hoger. Hiermee geeft u de vervaldatumoptie voor de aanvraag op. Zie ExpirationOption. Deze header is geldig voor accounts waarvoor hiërarchische naamruimte is ingeschakeld.
`x-ms-expiry-time`	Optioneel. Versie 2023-08-03 en hoger. Hiermee geeft u het tijdstip op waarop de blob is ingesteld om te verlopen. De notatie voor de vervaldatum is afhankelijk van `x-ms-expiry-option`. Zie ExpiryOption voor meer informatie. Deze header is geldig voor accounts waarvoor hiërarchische naamruimte is ingeschakeld. De `expiryTime` al aanwezig op een blob wordt niet gewist als de aanvraag geen nieuwe waarde van bevat `expiryTime`

Deze bewerking ondersteunt ook het gebruik van voorwaardelijke headers om de blokkeringslijst alleen door te voeren als aan een opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingen voor meer informatie.

Aanvraagheaders (door de klant verstrekte versleutelingssleutels)

Vanaf versie 2019-02-02 kunt u de volgende headers opgeven 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.

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

In de aanvraagbody kunt u de lijst met blokkeringen opgeven die door Blob Storage moet worden gecontroleerd op het aangevraagde blok. Op deze manier kunt u een bestaande blob bijwerken door afzonderlijke blokken in te voegen, te vervangen of te verwijderen, in plaats van de hele blob opnieuw te uploaden. Nadat u het blok of de blokken hebt geüpload die zijn gewijzigd, kunt u een nieuwe versie van de blob doorvoeren door de nieuwe blokken door te voeren samen met de bestaande blokken die u wilt behouden.

Als u een blob wilt bijwerken, kunt u opgeven dat de service eerst moet zoeken naar een blok-id in de lijst met vastgelegde blokkeringen, in de lijst met niet-doorgevoerde blokkeringen of in de lijst met niet-doorgevoerde blokkeringen en vervolgens in de lijst met vastgelegde blokkeringen. Als u wilt aangeven welke benadering moet worden gebruikt, geeft u als volgt de blok-id op die zich binnen het juiste XML-element in de aanvraagbody bevindt:

Geef de blok-id in het Committed -element op om aan te geven dat Blob Storage alleen in de lijst met vastgelegde blokkeringen naar het benoemde blok moet zoeken. Als het blok niet wordt gevonden in de lijst met vastgelegde blokkeringen, wordt het niet geschreven als onderdeel van de blob en retourneert Blob Storage statuscode 400 (Ongeldige aanvraag).
Geef de blok-id in het Uncommitted -element op om aan te geven dat Blob Storage alleen in de lijst met niet-doorgevoerde blokkeringen naar het benoemde blok moet zoeken. Als het blok niet wordt gevonden in de lijst met niet-verzonden blokkeringen, wordt het niet geschreven als onderdeel van de blob en retourneert Blob Storage statuscode 400 (Ongeldige aanvraag).
Geef de blok-id in het Latest -element op om aan te geven dat Blob Storage eerst in de lijst met niet-doorgevoerde blokkeringen moet zoeken. Als het blok wordt gevonden in de lijst niet-verzonden, is die versie van het blok de meest recente en moet deze naar de blob worden geschreven. Als het blok niet wordt gevonden in de niet-verzonden lijst, moet de service in de lijst met vastgelegde blokkeringen zoeken naar het benoemde blok en dat blok naar de blob schrijven als het wordt gevonden.

De aanvraagbody voor deze versie van Put Block List gebruikt de volgende XML-indeling:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>

Voorbeeldaanvraag

Ter illustratie Put Block Listwordt ervan uitgegaan dat u drie blokken hebt geüpload die u nu wilt doorvoeren. In het volgende voorbeeld wordt een nieuwe blob doorgevoerd door aan te geven dat de nieuwste versie van elk blok moet worden gebruikt. Het is niet nodig om te weten of deze blokken al zijn doorgevoerd.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>

Laten we nu aannemen dat u de blob wilt bijwerken. De nieuwe blob heeft de volgende wijzigingen:

Een nieuw blok met id ANAAAA==. Dit blok moet eerst worden geüpload met een aanroep naar Put Block en het wordt weergegeven in de lijst met niet-doorgevoerde blokkeringen tot de aanroep naar Put Block List.
Een bijgewerkte versie van het blok met id AZAAAA==. Dit blok moet eerst worden geüpload met een aanroep naar Put Block en het wordt weergegeven in de lijst met niet-doorgevoerde blokkeringen tot de aanroep naar Put Block List.
Verwijder het blok met de id AAAAAA==. Omdat dit blok niet is opgenomen in de volgende aanroep van Put Block List, wordt het blok effectief verwijderd uit de blob.

In het volgende voorbeeld ziet u de aanroep waarmee Put Block List de blob wordt bijgewerkt:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>

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.

Antwoord	Beschrijvingen
`ETag`	De entiteitstag bevat een waarde die de client kan gebruiken om voorwaardelijke `GET/PUT` bewerkingen uit te voeren met behulp van de `If-Match` aanvraagheader. Als de aanvraagversie 2011-08-18 of hoger is, staat de ETag-waarde tussen aanhalingstekens.
`Last-Modified`	De datum/tijd waarop de blob het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum-/tijdwaarden weergeven in kopteksten voor meer informatie. Elke bewerking die de blob wijzigt, inclusief een update van de metagegevens of eigenschappen van de blob, wijzigt de laatste wijzigingstijd van de blob.
`Content-MD5`	Geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. Deze header verwijst naar de inhoud van de aanvraag (in dit geval de lijst met blokken en niet de inhoud van de blob zelf). Voor versie 2019-02-02 en hoger wordt deze header alleen geretourneerd wanneer de aanvraag deze header heeft.
`x-ms-content-crc64`	Voor versie 2019-02-02 en hoger wordt deze header geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. Deze header verwijst naar de inhoud van de aanvraag (in dit geval de lijst met blokken en niet de inhoud van de blob zelf). 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`	De versie van Blob Storage die wordt gebruikt om de aanvraag uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn gemaakt op basis van versie 2009-09-19 en 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-version-id: <DateTime>`	Versie 2019-12-12 en hoger. Retourneert een ondoorzichtige `DateTime` waarde die de blob uniek identificeert. De waarde van deze header geeft de versie van de blob aan en kan worden gebruikt in volgende aanvragen voor toegang tot de blob.
`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 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

Autorisatie

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Put Block List bewerking autoriseren zoals hieronder wordt beschreven.

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

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 of service-principal om de Put Block List 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 List 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 indien mogelijk Microsoft Entra referenties om 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 met de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Put Block List 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 List 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
Lijst met blokkeringen plaatsen	Blob (b)	Object (o)	Schrijven (w)

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

Opmerkingen

De Put Block List bewerking dwingt de volgorde af waarin blokken moeten worden gecombineerd om een blob te maken.

Dezelfde blok-id kan meer dan één keer worden opgegeven in de lijst met blokken. Als een blok-id meer dan één keer wordt opgegeven, vertegenwoordigt deze het bereik van bytes in elk van deze locaties in de bloklijst voor de uiteindelijke vastgelegde blob. Als een blok-id meer dan één keer in de lijst voorkomt, moeten beide exemplaren van de blok-id worden opgegeven in dezelfde blokkeringslijst. Met andere woorden, beide exemplaren moeten worden opgegeven binnen het Committed element, het Uncommitted element of het Latest element.

Met Put Block Listkunt u een bestaande blob wijzigen door afzonderlijke blokken in te voegen, bij te werken of te verwijderen zonder dat u de hele blob opnieuw hoeft te uploaden. U kunt blok-id's opgeven uit zowel de huidige vastgelegde bloklijst als de niet-doorgevoerde bloklijst om een nieuwe blob te maken of de inhoud van een bestaande blob bij te werken. Op deze manier kunt u een blob bijwerken door enkele nieuwe blokken op te geven uit de lijst met niet-doorgevoerde blokken en de rest van de lijst met vastgelegde blokkeringen, die al deel uitmaken van de bestaande blob.

Als er een blok-id is opgegeven in het Latest -element en dezelfde blok-id bestaat in zowel de vastgelegde als de niet-doorgevoerde bloklijst, Put Block List voert u het blok uit de lijst met niet-verzonden blokkeringen door. Als de blok-id bestaat in de lijst met vastgelegde blokkeringen, maar niet in de lijst met niet-doorgevoerde blokkeringen, Put Block List voert u het blok uit de lijst met vastgelegde blokkeringen door.

Elk blok in een blok-blob kan een andere grootte hebben. Een blok-blob kan maximaal 50.000 toegewezen blokken bevatten. Het maximum aantal niet-doorgevoerde blokken dat aan een blob kan worden gekoppeld, is 100.000.

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	4000 mebibytes (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 GiB (4 MiB × 50.000 blokken)	64 MiB

Wanneer u aanroept Put Block List om een bestaande blob bij te werken, worden de bestaande eigenschappen en metagegevens van de blob overschreven. Bestaande momentopnamen blijven echter behouden met de blob. U kunt de headers voor voorwaardelijke aanvragen gebruiken om de bewerking alleen uit te voeren als aan een opgegeven voorwaarde wordt voldaan.

Als de Put Block List bewerking mislukt vanwege een ontbrekend blok, moet u het ontbrekende blok uploaden.

Niet-verzonden blokken worden verzameld als er binnen een week na de laatste geslaagde Put Block bewerking geen geslaagde aanroepen naar Put Block of Put Block List op de blob zijn. Als Put Blob wordt aangeroepen op de blob, worden alle niet-doorgevoerde blokken garbagecollection.

Als tags zijn opgegeven in de x-ms-tags header, moeten ze worden gecodeerd met querytekenreeksen. Tagsleutels en -waarden moeten voldoen aan de vereisten voor naamgeving en lengte, zoals opgegeven in Set Blob Tags. Verder kan de x-ms-tags header tags van maximaal 2 KiB in grootte bevatten. Als er meer tags vereist zijn, gebruikt u de bewerking Blobtags instellen .

Als de blob een actieve lease heeft, moet de client een geldige lease-id opgeven voor de aanvraag om de blokkeringslijst door te voeren. 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). Als de client een lease-id opgeeft voor een blob die nog niet bestaat, retourneert Blob Storage statuscode 412 (Voorwaarde mislukt) voor aanvragen die zijn gedaan in versie 2013-08-15 of hoger. Voor eerdere versies retourneert Blob Storage statuscode 201 (gemaakt).

Als de blob een actieve lease heeft en u aanroept Put Block List om de blob bij te werken, wordt de lease gehandhaafd op de bijgewerkte blob.

Put Block List is alleen van toepassing op blok-blobs. Het aanroepen Put Block List op een pagina-blob resulteert in statuscode 400 (ongeldige aanvraag).

Het overschrijven van een gearchiveerde blob mislukt en het overschrijven van een hot of-blob cool neemt de laag over van de oude blob als de x-ms-access-tier-header niet is opgegeven.

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 hebben bijvoorbeeld een andere factureringscategorie dan schrijftransacties. In de volgende tabel ziet u de factureringscategorie voor Put Block List aanvragen op basis van het type opslagaccount:

Bewerking	Type opslagaccount	Factureringscategorie
Lijst met blokkeringen plaatsen	Premium blok-blob Standaard v2 voor algemeen gebruik Standaard v1 voor algemeen gebruik	Schrijfbewerkingen

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

Zie ook

Informatie over blok-blobs, toevoeg-blobs en pagina-blobs
Aanvragen autoriseren voor Azure Storage
Status en foutcodes
Foutcodes voor blob-service
Time-outs instellen voor Blob-servicebewerkingen