Lijst met blokken plaatsen

De Put Block List operatie schrijft een blob door de lijst van blok-ID's te specificeren waaruit de blob bestaat. Om als onderdeel van een blob te worden geschreven, moet een blok succesvol naar de server zijn geschreven in een eerdere Put Block-operatie .

Je kunt een blob Put Block List bijwerken door alleen die blokken te uploaden die zijn veranderd en vervolgens de nieuwe en bestaande blokken samen te committen. Je kunt dit doen door aan te geven of je een blokkade wilt committen uit de committed block list of uit de niet-committed blocklijst, of de meest recent geüploade versie van de block committen, afhankelijk van de lijst waar het bij hoort.

Verzoek

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

De opslagemulator ondersteunt alleen blobgroottes tot 2 gibibyte (GiB).

Zie 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:

Kenmerk Beschrijving
timeout Optioneel. De parameter timeout wordt uitgedrukt in seconden. Voor meer informatie, zie Stel timeouts in voor Blob-serviceoperaties.

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.
Content-Length Verplicht. De lengte van de verzoekinhoud, in bytes. Deze header 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 verzoekinhoud, en niet aan de inhoud van de blob zelf.
x-ms-content-crc64 Optioneel. Een CRC64-hash van de verzoekinhoud. 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 verzoekinhoud, en niet aan de inhoud van de blob zelf.

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 versie 2019-02-02 en later.
x-ms-blob-cache-control Optioneel. Stelt de cachecontrole van de blob in. Als deze eigenschap is gespecificeerd, wordt deze opgeslagen bij de blob en teruggegeven met een leesverzoek.

Als de eigenschap niet is gespecificeerd bij het verzoek, wordt deze gecleared voor de blob als het verzoek succesvol is.
x-ms-blob-content-type Optioneel. Stelt het inhoudstype van de blob in. Als dit is gespecificeerd, wordt deze eigenschap opgeslagen bij de blob en teruggegeven met een leesverzoek.

Als het contenttype niet is opgegeven, wordt het ingesteld op het standaardtype, namelijk application/octet-stream.
x-ms-blob-content-encoding Optioneel. Stelt de content-codering van de blob in. Als dit is gespecificeerd, wordt deze eigenschap opgeslagen bij de blob en teruggegeven met een leesverzoek.

Als de eigenschap niet is gespecificeerd bij het verzoek, wordt deze gecleared voor de blob als het verzoek succesvol is.
x-ms-blob-content-language Optioneel. Stelt de inhoudstaal van de blob in. Als dit is gespecificeerd, wordt deze eigenschap opgeslagen bij de blob en teruggegeven met een leesverzoek.

Als de eigenschap niet is gespecificeerd bij het verzoek, wordt deze gecleared voor de blob als het verzoek succesvol is.
x-ms-blob-content-md5 Optioneel. Een MD5-hash van de blob-inhoud. Deze hash wordt niet gevalideerd, omdat de hashes voor de individuele blokken werden gevalideerd toen elk blok werd geüpload.

De Get Blob-operatie geeft de waarde van deze header terug in de Content-MD5 response-header.

Als deze eigenschap niet is gespecificeerd bij het verzoek, wordt deze gewist voor de blob als het verzoek succesvol is.
x-ms-meta-name:value Optioneel. Door de gebruiker gedefinieerde naam-waardeparen die aan de blob zijn gekoppeld.

Vanaf versie 2009-09-19 moeten metadatanamen voldoen aan de naamgevingsregels voor C#-identificaties.
x-ms-encryption-scope Optioneel. Geeft de encryptiescope aan die gebruikt moet worden om de blob te versleutelen. Deze waarde moet overeenkomen met de encryptiescope die wordt gebruikt om alle blokken die worden gecommitted te versleutelen. Deze header wordt ondersteund in versie 2019-02-02 en later.
x-ms-encryption-context Optioneel. Standaard is "Leeg". Als de waarde is ingesteld, wordt de blob-systeemmetadata 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 later.
x-ms-tags Optioneel. Zet de gespecificeerde query-string gecodeerde tags op de blob. Voor meer informatie, zie de sectie Opmerkingen . 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 tekenlimiet van 1 kibibyte (KiB) die wordt vastgelegd in de analyticslogs wanneer storage analytics logging 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.
x-ms-blob-content-disposition Optioneel. Stelt de Content-Disposition kop van de blob in. Beschikbaar voor versie 2013-08-15 en hoger.

Het Content-Disposition headerveld geeft extra informatie over hoe de responspayload verwerkt moet worden, en kan worden gebruikt om extra metadata toe te voegen. Als het bijvoorbeeld is ingesteld op attachment, geeft deze header aan dat de user-agent het antwoord niet moet tonen, maar in plaats daarvan een opslaan als-dialoog.

De respons van de Get Blob - en Get Blob Properties-operaties bevat de content-disposition header.
x-ms-access-tier Optioneel. Versie 2018-11-09 en later. Geeft aan welk niveau op een blob moet worden gezet. Voor block blobs wordt deze header alleen ondersteund op blob storage of algemene v2-accounts vanaf versie 2018-11-09 en later. Geldige waarden voor blokblob-tiers zijn Hot, , , Colden SmartArchiveCool.
Opmerking:Cold laag wordt ondersteund voor versie 2021-12-02 en hoger. Smart Tier wordt ondersteund voor versie 2026-02-06 en later, en bevindt zich momenteel in de openbare preview.
Voor gedetailleerde informatie over block blob tiering, zie Blob storage tiers.
x-ms-immutability-policy-until-date Versie 2020-06-12 en later. Specificeert de behoudsdatum die op de blob moet worden vastgesteld. Dit is de datum tot wanneer de blob kan worden beveiligd tegen wijziging of verwijdering. Volgt RFC1123 format.
x-ms-immutability-policy-mode Versie 2020-06-12 en later. Specificeert de onveranderlijkheidsbeleidsmodus die op de blob moet worden ingesteld. Geldige waarden zijn unlocked en locked. De unlocked waarde geeft aan dat gebruikers het beleid kunnen wijzigen door de retentie-tot-datum te verhogen of te verlagen. De locked waarde geeft aan dat deze handelingen verboden zijn.
x-ms-legal-hold Versie 2020-06-12 en later. Specificeert de wettelijke houvast die op de blob moet worden ingesteld. De geldige waarden zijn true en false.
x-ms-expiry-option Optioneel. Versie 2023-08-03 en later. Specificeert de vervaldatumoptie voor het verzoek, zie VerloopOption. Deze header is geldig voor accounts met hiërarchische naamruimte ingeschakeld.
x-ms-expiry-time Optioneel. Versie 2023-08-03 en later. Geeft het tijdstip aan waarop de blob verloopt. Het format voor de houdbaarheidsdatum varieert volgens x-ms-expiry-option. Voor meer informatie, zie ExpiryOption. Deze header is geldig voor accounts met hiërarchische naamruimte ingeschakeld.

De expiryTime reeds aanwezige op een blob wordt niet gewist als het verzoek geen nieuwe waarde van bevat expiryTime

Deze operatie ondersteunt ook het gebruik van conditionele headers om de bloklijst alleen te committen als aan een gespecificeerde voorwaarde is voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingenvoor meer informatie.

Aanvraagheaders (door de klant verstrekte coderingssleutels)

Vanaf versie 2019-02-02 kun je de volgende headers op het verzoek specificeren 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 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.

aanvraaginhoud

In de request body kun je de bloklijst specificeren die Blob Storage moet controleren op het gevraagde blok. Op deze manier kun je een bestaande blob bijwerken door individuele blokken in te voegen, te vervangen of te verwijderen, in plaats van de hele blob opnieuw te uploaden. Nadat je het blok of de blokken die zijn veranderd hebt geüpload, kun je een nieuwe versie van de blob committen door de nieuwe blokken samen met de bestaande blokken die je wilt behouden te committen.

Om een blob bij te werken, kun je specificeren dat de service eerst moet zoeken naar een blok-ID in de lijst met toegewijde blokken, in de niet-toegewijde bloklijst, of eerst in de niet-toegewijde bloklijst en daarna in de toegewijde bloklijst. Om aan te geven welke aanpak gebruikt moet worden, specificeer je de blok-ID die zich binnen het juiste XML-element binnen de verzoekbody bevindt, als volgt:

  • Specificeer de blok-ID binnen het Committed element om aan te geven dat Blob Storage alleen in de lijst van gecommitteerde blokken moet zoeken naar het benoemde blok. Als het blok niet wordt gevonden in de lijst met toegewijde blokken, wordt het niet als onderdeel van de blob geschreven, en geeft Blob Storage statuscode 400 (Bad Request) terug.

  • Specificeer de blok-ID binnen het Uncommitted element om aan te geven dat Blob Storage alleen de lijst met niet-committed blokken moet doorzoeken naar het benoemde blok. Als het blok niet wordt gevonden in de niet-toegewijde bloklijst, wordt het niet als onderdeel van de blob geschreven, en geeft Blob Storage statuscode 400 (Bad Request) terug.

  • Specificeer de blok-ID binnen het Latest element om aan te geven dat Blob Storage eerst de lijst met niet-toegewijde blokken moet doorzoeken. Als het blok in de niet-committed lijst wordt gevonden, is die versie van het blok de nieuwste en moet deze naar de blob worden geschreven. Als de blokkade niet wordt gevonden in de niet-committed lijst, zou de service de gecommitteerde bloklijst moeten doorzoeken naar het benoemde blok en dat blok naar de blob moeten schrijven als het wordt gevonden.

De aanvraagbody voor deze versie van Put Block List gebruikt het volgende XML-formaat:

<?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

Om het aan te tonen Put Block List, ga ervan uit dat je drie blokken hebt geüpload die je wilt committeren. Het volgende voorbeeld commit een nieuwe blob door aan te geven dat de nieuwste versie van elk vermeld blok gebruikt moet worden. Het is niet nodig om te weten of deze blokkades al zijn gepleegd.

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 vervolgens aannemen dat je de blob wilt bijwerken. De nieuwe blob heeft de volgende wijzigingen:

  • Een nieuw blok met ID ANAAAA==. Deze blokkade moet eerst worden geüpload met een aanroep naar Put Block, en verschijnt in de niet-committed blocklijst tot de oproep naar Put Block List.

  • Een bijgewerkte versie van het blok met ID AZAAAA==. Deze blokkade moet eerst worden geüpload met een aanroep naar Put Block, en verschijnt in de niet-committed blocklijst tot de oproep naar Put Block List.

  • Verwijdering van het blok met de ID AAAAAA==. Omdat dit blok niet is opgenomen in de volgende aanroep naar Put Block List, wordt het blok effectief uit de blob verwijderd.

Het volgende voorbeeld toont de aanroep naar Put Block List die de blob bijwerkt:

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 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.

Antwoord Beschrijvingen
ETag De entiteitstag bevat een waarde die de client kan gebruiken om conditionele GET/PUT operaties uit te voeren via de If-Match requestheader. Als de aanvraagversie 2011-08-18 of hoger is, wordt de ETag-waarde tussen aanhalingstekens geplaatst.
Last-Modified De datum/tijd waarop de blob voor het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum-/tijdwaarden weergeven in koptekstenvoor meer informatie.

Elke bewerking waarmee de blob wordt gewijzigd, inclusief een update van de metagegevens of eigenschappen van de blob, wijzigt de laatste wijzigingstijd van de blob.
Content-MD5 Teruggegeven zodat de client kan controleren op de integriteit van de boodschapinhoud. Deze header verwijst naar de inhoud van het verzoek (in dit geval de lijst met blokken en niet naar de inhoud van de blob zelf). Voor versie 2019-02-02 en later wordt deze header alleen teruggegeven wanneer het verzoek deze header heeft.
x-ms-content-crc64 Voor versie 2019-02-02 en later wordt deze header teruggegeven zodat de client kan controleren op de integriteit van de berichtinhoud. Deze header verwijst naar de inhoud van het verzoek (in dit geval de lijst met blokken en niet naar de inhoud van de blob zelf).

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 De versie van Blob Storage die wordt gebruikt om het verzoek uit te voeren. Deze header wordt geretourneerd voor aanvragen die zijn ingediend tegen versie 2009-09-19 en hoger.
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 hoger. Deze header wordt teruggegeven als het verzoek een door de klant verstrekte sleutel voor versleuteling gebruikte, zodat de client kan garanderen dat de inhoud van het verzoek succesvol is versleuteld door de geleverde sleutel te gebruiken.
x-ms-encryption-scope Versie 2019-02-02 en hoger. 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-version-id: <DateTime> Versie 2019-12-12 en later. Retourneert een ondoorzichtige DateTime waarde die de blob uniek identificeert. De waarde van deze header geeft de versie van de blob aan, en deze kan in latere verzoeken worden gebruikt om toegang te krijgen tot de blob.
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.

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 verzoek tags specificeert met de x-ms-tags requestheader, moet de caller voldoen aan de autorisatievereisten van de Set Blob Tags-operatie .

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.

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.

toestemmingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Put Block List-bewerking aan te roepen, en de minst bevoorrechte ingebouwde Azure RBAC-rol die deze actie omvat:

Zie Een Azure-rol toewijzen voor toegang tot blobgegevensvoor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.

Opmerkingen

De Put Block List operatie handhaaft de volgorde waarin blokken worden gecombineerd om een blob te vormen.

Dezelfde blok-ID kan meer dan eens worden opgegeven in de lijst van blokken. Als een blok-ID meer dan één keer wordt gespecificeerd, vertegenwoordigt het het bereik van bytes op elk van die locaties in de bloklijst voor de laatste toegewezen blob. Als een blok-ID meer dan eens in de lijst voorkomt, moeten beide instanties van de blok-ID binnen dezelfde bloklijst worden gespecificeerd. Met andere woorden, beide instanties moeten binnen het Committed element, het Uncommitted element of het Latest element worden gespecificeerd.

Met Put Block List, kun je een bestaande blob aanpassen door individuele blokken in te voegen, bij te werken of te verwijderen zonder de hele blob opnieuw te hoeven uploaden. Je kunt blok-ID's specificeren van zowel de huidige toegewijde bloklijst als de niet-gecommitteerde bloklijst om een nieuwe blob te creëren of de inhoud van een bestaande blob bij te werken. Op deze manier kun je een blob bijwerken door een paar nieuwe blokken uit de niet-gecommitteerde bloklijst te specificeren, en de rest uit de toegewijde bloklijst, die al deel uitmaken van de bestaande blob.

Als een blok-ID in het Latest element is gespecificeerd, en dezelfde blok-ID bestaat in zowel de gecommitteerde als niet-gecommitteerde bloklijsten, Put Block List commit het blok uit de niet-gecommitteerde bloklijst. Als de blok-ID in de gecommitteerde bloklijst bestaat maar niet in de niet-toegewijde bloklijst, Put Block List commit het blok uit de gecommitteerde bloklijst.

Elk blok in een blok kan een andere grootte hebben. Een block blob kan maximaal 50.000 gecommitteerde blokken bevatten. Het maximale aantal niet-toegewijde blokken dat aan een blob kan worden gekoppeld is 100.000.

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

Wanneer je een Put Block List bestaande blob wilt updaten, worden de bestaande eigenschappen en metadata van de blob overschreven. Echter, bestaande snapshots blijven bij de blob behouden. Je kunt de conditionele requestheaders gebruiken om de operatie alleen uit te voeren als aan een gespecificeerde voorwaarde is voldaan.

Als de Put Block List operatie faalt door een ontbrekend blok, moet je het ontbrekende blok uploaden.

Niet-committed blokken worden garbage collected als er binnen een week na de laatste succesvolle Put Block operatie geen succesvolle oproepen naar Put Block of Put Block List op de blob zijn. Als Put Blob op de blob wordt aangeroepen, worden alle niet-committed blokken garbage collecte gemaakt.

Als tags in de x-ms-tags header worden gegeven, moeten ze met querystring-codering worden gecodeerd. Tagsleutels en -waarden moeten voldoen aan de naamgevings- en lengtevereisten, zoals gespecificeerd in Set Blob Tags. Bovendien kan de x-ms-tags header tags tot 2 KiB bevatten. Als er meer tags nodig zijn, gebruik dan de Set Blob Tags-operatie .

Als de blob een actieve lease heeft, moet de client een geldig lease-ID opgeven op het verzoek om de blocklijst te committen. 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. Als de client een lease-ID specificeert op een blob die nog niet bestaat, geeft Blob Storage statuscode 412 (Precondition Failed) terug voor verzoeken die zijn gedaan tegen versie 2013-08-15 of later. Voor eerdere versies geeft Blob Storage statuscode 201 (Aangemaakt) terug.

Als de blob een actieve lease heeft en je belt Put Block List om de blob bij te werken, wordt de lease behouden op de bijgewerkte blob.

Put Block List geldt alleen voor blokklontjes. Het aanroepen Put Block List van een page blob resulteert in statuscode 400 (Bad Request).

Het overschrijven van een archive blob faalt. Anders erft een blob de tier van de oude blob als er geen x-ms-access-tier header wordt geleverd.

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 List aanvragen op basis van het type opslagaccount:

Operatie Type opslagaccount Factureringscategorie
Lijst met blokken plaatsen Premium blok-blob
Standaard algemeen gebruik v2
Standaard algemeen gebruik v1		 Schrijfbewerkingen

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

Zie ook

Begrijp block blobs, append blobs en page blobs
aanvragen autoriseren voor Azure Storage
status en foutcodes
Blob service foutcodes
Stel time-outs in voor Blob-serviceoperaties

  • Last updated on