Lijst met blokkeringen ophalen
Met Get Block List
de bewerking wordt de lijst met blokken opgehaald die zijn geüpload als onderdeel van een blok-blob.
Er worden twee bloklijsten onderhouden voor een blob:
Lijst met vastgelegde blokkeringen: de lijst met blokken die zijn doorgevoerd naar een opgegeven blob met behulp van Put Block List.
Lijst met niet-doorgevoerde blokkeringen: de lijst met blokken die zijn geüpload voor een blob met behulp van Put Block, maar die nog niet zijn doorgevoerd. Deze blokken worden in Azure opgeslagen in combinatie met een blob, maar maken nog geen deel uit van de blob.
U kunt aanroepen Get Block List
om de vastgelegde blokkeringslijst, de niet-doorgevoerde blokkeringslijst of beide lijsten te retourneren. U kunt deze bewerking ook aanroepen om de vastgelegde blokkeringslijst voor een momentopname op te halen.
Aanvraag
De Get Block List
aanvraag kan als volgt worden samengesteld. U wordt aangeraden HTTPS te gebruiken. Vervang myaccount door de naam van uw opslagaccount:
GET-methode-aanvraag-URI | HTTP-versie |
---|---|
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist&snapshot=<DateTime> https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist&versionid=<DateTime> |
HTTP/1.1 |
Aanvraag voor geëmuleerde opslagservice
Wanneer u een aanvraag voor de geëmuleerde opslagservice maakt, 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:
GET-methode-aanvraag-URI | HTTP-versie |
---|---|
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist |
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
U kunt de volgende aanvullende parameters opgeven voor de aanvraag-URI:
URI-parameter | Beschrijving |
---|---|
snapshot |
Optioneel. De parameter momentopname is een ondoorzichtige DateTime waarde die, indien aanwezig, de bloblijst aangeeft die moet worden opgehaald. Zie een momentopname van een blob Creatie voor meer informatie over het werken met blobmomentopnamen. |
versionid |
Optioneel voor versies 2019-12-12 en hoger. De versionid parameter is een ondoorzichtige DateTime waarde die, indien aanwezig, de versie van de op te halen blob aangeeft. |
blocklisttype |
Hiermee geeft u op of de lijst met vastgelegde blokken, de lijst met niet-doorgevoerde blokken of beide lijsten samen moet retourneren. Geldige waarden zijn committed , uncommitted of all . Als u deze parameter weglaat, Get Block List retourneert de lijst met vastgelegde blokken. |
timeout |
Optioneel. De timeout parameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie. |
Aanvraagheaders
In de volgende tabel worden vereiste en optionele aanvraagheaders beschreven.
Aanvraagheader | Beschrijving |
---|---|
Authorization |
Vereist. Hiermee geeft u het autorisatieschema, de accountnaam en de handtekening. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie. |
Date of x-ms-date |
Vereist. Geef de Coordinated Universal Time (UTC) op voor de aanvraag. Zie Aanvragen voor Azure Storage autoriseren voor meer informatie. |
x-ms-version |
Vereist voor alle geautoriseerde aanvragen, optioneel voor anonieme aanvragen. Hiermee geeft u de versie van de bewerking te gebruiken voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-services voor meer informatie. |
x-ms-lease-id:<ID> |
Optioneel. Als deze header is opgegeven, wordt de bewerking alleen uitgevoerd als aan beide van de volgende voorwaarden wordt voldaan: - De lease van de blob is momenteel actief. - De lease-id die in de aanvraag is opgegeven, komt overeen met die van de blob. Als deze header is opgegeven en er niet aan een van de voorwaarden wordt voldaan, mislukt de aanvraag en mislukt de bewerking met statuscode 412 (voorwaarde mislukt). |
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. |
Deze bewerking ondersteunt ook het gebruik van voorwaardelijke headers om de bewerking alleen uit te voeren als aan een opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingen voor meer informatie.
Aanvraagbody
Geen.
Voorbeeldaanvraag
De volgende voorbeeldaanvraag-URI retourneert de vastgelegde blokkeringslijst voor een blob met de naam MOV1.avi:
GET http://myaccount.blob.core.windows.net/movies/MOV1.avi?comp=blocklist&blocklisttype=committed HTTP/1.1
De volgende voorbeeldaanvraag-URI retourneert zowel de vastgelegde als de niet-doorgevoerde blokkeringslijst:
GET http://myaccount.blob.core.windows.net/movies/MOV1.avi?comp=blocklist&blocklisttype=all HTTP/1.1
De volgende voorbeeldaanvraag-URI retourneert de vastgelegde blokkeringslijst voor een momentopname. Een momentopname bestaat alleen uit vastgelegde blokken, dus er zijn geen niet-doorgevoerde blokken aan gekoppeld.
GET http://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist&snapshot=2009-09-30T20%3a11%3a15.2735974Z
Antwoord
Het antwoord bevat een HTTP-statuscode, een set antwoordheaders en een antwoordtekst die de lijst met blokken bevat.
Statuscode
Een geslaagde bewerking retourneert statuscode 200 (OK).
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.
Antwoordheader | Description |
---|---|
Last-Modified |
De datum/tijd waarop de blob voor het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum-/tijdwaarden weergeven in kopteksten voor meer informatie. Alleen geretourneerd als de blob toegewezen blokken heeft. Elke bewerking die de blob wijzigt, inclusief updates van de metagegevens of eigenschappen van de blob, wijzigt de laatste wijzigingstijd van de blob. |
ETag |
De ETag voor de blob. Alleen geretourneerd als de blob toegewezen blokken heeft. |
Content-Type |
Het MIME-inhoudstype van de blob. De standaardwaarde is application/xml . |
x-ms-blob-content-length |
De grootte van de blob in bytes. |
x-ms-request-id |
Deze header identificeert op unieke wijze de aanvraag die is gedaan en kan worden gebruikt om problemen met de aanvraag op te lossen. Zie Problemen met API-bewerkingen oplossen voor meer informatie. |
x-ms-version |
Geeft de serviceversie 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 en hoger. Deze header wordt ook geretourneerd voor anonieme aanvragen zonder een opgegeven versie als de container is gemarkeerd voor openbare toegang met Blob Storage versie 2009-09-19. Opmerking: alleen de vastgelegde blokkeringslijst kan worden geretourneerd via een anonieme aanvraag. |
Date |
Een UTC-datum/tijd-waarde die wordt gegenereerd door de service, die de tijd aangeeft waarop het antwoord is gestart. |
x-ms-client-request-id |
Kan worden gebruikt om problemen met aanvragen en bijbehorende antwoorden op te lossen. De waarde van deze header is gelijk aan de waarde van de x-ms-client-request-id header als deze aanwezig is in de aanvraag en de waarde niet meer dan 1024 zichtbare ASCII-tekens bevat. Als de x-ms-client-request-id header niet aanwezig is in de aanvraag, is deze niet aanwezig in het antwoord. |
Deze bewerking ondersteunt ook het gebruik van voorwaardelijke headers om de blokkeringslijst alleen op te halen als aan een opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingen voor meer informatie.
Hoofdtekst van de reactie
De indeling van de antwoordtekst voor een aanvraag die alleen vastgelegde blokken retourneert, is als volgt:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks>
<Block>
<Name>base64-encoded-block-id</Name>
<Size>size-in-bytes</Size>
</Block>
<CommittedBlocks>
</BlockList>
De indeling van de antwoordtekst voor een aanvraag die zowel vastgelegde als niet-doorgevoerde blokken retourneert, is als volgt:
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks>
<Block>
<Name>base64-encoded-block-id</Name>
<Size>size-in-bytes</Size>
</Block>
</CommittedBlocks>
<UncommittedBlocks>
<Block>
<Name>base64-encoded-block-id</Name>
<Size>size-in-bytes</Size>
</Block>
</UncommittedBlocks>
</BlockList>
Voorbeeldantwoord
In het volgende voorbeeld is de blocklisttype
parameter ingesteld op committed
, zodat alleen de vastgelegde blokken van de blob worden geretourneerd in het antwoord.
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/xml
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 42da571d-34f4-4d3e-b53e-59a66cb36f23
Date: Sun, 25 Sep 2011 00:33:19 GMT
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks>
<Block>
<Name>BlockId001</Name>
<Size>4194304</Size>
</Block>
<Block>
<Name>BlockId002</Name>
<Size>4194304</Size>
</Block>
</CommittedBlocks>
</BlockList>
In dit voorbeeld is de blocklisttype
parameter ingesteld op all
en worden zowel de vastgelegde als de niet-doorgevoerde blokken van de blob geretourneerd in het antwoord.
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/xml
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 42da571d-34f4-4d3e-b53e-59a66cb36f23
Date: Sun, 25 Sep 2011 00:35:56 GMT
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks>
<Block>
<Name>BlockId001</Name>
<Size>4194304</Size>
</Block>
<Block>
<Name>BlockId002</Name>
<Size>4194304</Size>
</Block>
</CommittedBlocks>
<UncommittedBlocks>
<Block>
<Name>BlockId003</Name>
<Size>4194304</Size>
</Block>
<Block>
<Name>BlockId004</Name>
<Size>1024000</Size>
</Block>
</UncommittedBlocks>
</BlockList>
In dit volgende voorbeeld is de blocklisttype
parameter ingesteld op all
, maar de blob is nog niet doorgevoerd, dus het CommittedBlocks
element is leeg.
HTTP/1.1 200 OK
Transfer-Encoding: chunked
Content-Type: application/xml
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-request-id: 42da571d-34f4-4d3e-b53e-59a66cb36f23
Date: Wed, 14 Sep 2011 00:40:22 GMT
<?xml version="1.0" encoding="utf-8"?>
<BlockList>
<CommittedBlocks />
<UncommittedBlocks>
<Block>
<Name>BlockId001</Name>
<Size>1024</Size>
</Block>
<Block>
<Name>BlockId002</Name>
<Size>1024</Size>
</Block>
<Block>
<Name>BlockId003</Name>
<Size>1024</Size>
</Block>
<Block>
<Name>BlockId004</Name>
<Size>1024</Size>
</Block>
</UncommittedBlocks>
</BlockList>
Autorisatie
Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Get Block List
bewerking autoriseren zoals hieronder wordt beschreven.
Belangrijk
Microsoft raadt aan 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 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, beheerde identiteit of service-principal om de Get 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/read
- Ingebouwde rol met minimale bevoegdheden:Lezer voor opslagblobgegevens
Zie Een Azure-rol toewijzen voor toegang tot blobgegevens voor meer informatie over het toewijzen van rollen met behulp van Azure RBAC.
Opmerkingen
Roep Get Block List
aan om de lijst met blokken te retourneren die zijn doorgevoerd in een blok-blob, de lijst met blokken die nog niet zijn doorgevoerd of beide lijsten. Gebruik de blocklisttype
parameter om op te geven welke lijst met blokken moet worden geretourneerd. De lijst met vastgelegde blokken wordt geretourneerd in dezelfde volgorde als ze zijn doorgevoerd door de bewerking Lijst met blokkeringen plaatsen .
U kunt de niet-doorgevoerde blokkeringslijst gebruiken om te bepalen welke blokken ontbreken in de blob in gevallen waarin aanroepen naar Put Block
of Put Block List
zijn mislukt. De lijst met niet-doorgevoerde blokken wordt in alfabetische volgorde geretourneerd. Als een blok-id meerdere keren is geüpload, wordt alleen het laatst geüploade blok in de lijst weergegeven.
Notitie
Wanneer een blob nog niet is doorgevoerd, retourneert het aanroepen Get Block List
met blocklisttype=all
de niet-doorgevoerde blokken en is het CommittedBlocks
element leeg.
Get Block List
biedt geen ondersteuning voor gelijktijdigheid wanneer de lijst met niet-doorgevoerde blokken wordt gelezen. Aanroepen naar Get Block List
waar blocklisttype=uncommitted
of blocklisttype=all
een lagere maximale aanvraagsnelheid hebben dan andere leesbewerkingen. Zie Schaalbaarheids- en prestatiedoelen voor Azure Storage voor meer informatie over de doeldoorvoer voor leesbewerkingen.
Vanaf versie 2019-12-12 kan een blok-blob blokken van maximaal 4000 mebibytes (MiB) bevatten. Als u toepassingen wilt beveiligen die een ondertekend 32-bits geheel getal gebruiken om de blokgrootte aan te geven, resulteert het aanroepen Get Block List
van een blok-blob die een blok groter dan 100 MiB bevat met een REST-versie ouder dan 2019-12-12 in statuscode 409 (Conflict).
Get Block List
is alleen van toepassing op blok-blobs. Het aanroepen van Get Block List
een pagina-blob resulteert in statuscode 400 (Ongeldige aanvraag).
Get Block List
op een gearchiveerde blok-blob mislukt.
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 Get Block List
aanvragen op basis van het type opslagaccount:
Bewerking | Type opslagaccount | Factureringscategorie |
---|---|---|
Lijst met blokkeringen ophalen | Premium-blok-blob Standard v2 voor algemeen gebruik |
Andere bewerkingen |
Lijst met blokkeringen ophalen | Standard v1 voor algemeen gebruik | Leesbewerkingen |
Zie prijzen voor Azure Blob Storage voor meer informatie over prijzen voor de opgegeven factureringscategorie.
Zie ook
Aanvragen autoriseren voor Azure Storage-statusen foutcodesBlob Storage-foutcodesTime-outs instellen voor Blob Storage-bewerkingen