Blok toevoegen van URL

Met Append Block From URL deze bewerking wordt een nieuw gegevensblok vastgelegd aan het einde van een bestaande toevoeg-blob.

De Append Block From URL bewerking is alleen toegestaan als de blob is gemaakt met x-ms-blob-type ingesteld op AppendBlob. Append Block From URL Wordt alleen ondersteund op versie 2018-11-09 of hoger.

Aanvraag

U kunt de Append Block From URL aanvraag als volgt samenstellen. HTTPS wordt aanbevolen. Vervang myaccount- door de naam van uw opslagaccount.

PUT methode URI aanvragen	HTTP-versie
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock`	HTTP/1.1

Wanneer u een aanvraag indient voor de geëmuleerde opslagservice, geeft u de hostnaam van de emulator en de Azure Blob Storage-poort op als 127.0.0.1:10000, gevolgd door de naam van het geëmuleerde opslagaccount.

PUT methode URI aanvragen	HTTP-versie
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=appendblock`	HTTP/1.1

Zie De Azurite-emulator gebruiken voor lokale Azure Storage-ontwikkelingvoor meer informatie.

URI Parameters

Kenmerk	Beschrijving
`timeout`	Facultatief. De time-outparameter wordt uitgedrukt in seconden. Zie Time-outs instellen voor Blob Storage-bewerkingen voor meer informatie.

Headers aanvragen

In de volgende tabel worden de vereiste en optionele aanvraagheaders beschreven.

Header van het verzoek	Beschrijving
`Authorization`	Verplicht. 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`	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. Hiermee geeft u het aantal bytes dat wordt verzonden in de aanvraagbody. De waarde van deze kop moet op nul worden gezet. Als de lengte niet nul is, mislukt de bewerking met foutcode 400 (Ongeldig verzoek).
`x-ms-copy-source:name`	Verplicht. Hiermee geeft u de URL van de bron-blob op. De waarde kan een URL zijn van maximaal 2 KiB lang die een blob aangeeft. De waarde moet URL-gecodeerd zijn, zoals deze wordt weergegeven in een aanvraag-URI. De bron-blob moet openbaar zijn of moet zijn geautoriseerd via een handtekening voor gedeelde toegang. Als de bron-blob openbaar is, is er geen autorisatie vereist om de bewerking uit te voeren. Hier volgen enkele voorbeelden van URL's voor bronobjecten: `https://myaccount.blob.core.windows.net/mycontainer/myblob` `https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>` `https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>`
`x-ms-copy-source-authorization: <scheme> <signature>`	Facultatief. Hiermee geeft u het autorisatieschema en de handtekening voor de bron van de kopie op. Zie Aanvragen autoriseren voor Azure Storagevoor meer informatie. Alleen schemadrager wordt ondersteund voor Microsoft Entra-ID. Deze header wordt ondersteund in versie 2020-10-02 en hoger.
`x-ms-source-range`	Facultatief. Uploadt alleen de bytes van de blob in de bron-URL in het opgegeven bereik. Als dit niet is opgegeven, wordt de volledige inhoud van de bron-blob geüpload als één toevoegblok. Zie De bereikheader opgeven voor Blob Storage-bewerkingen voor meer informatie.
`x-ms-source-content-md5`	Facultatief. Een MD5-hash van de toevoegblokinhoud van de URI. Deze hash wordt gebruikt om de integriteit van het toevoegblok te controleren tijdens het transport van de gegevens van de URI. Wanneer u deze header opgeeft, vergelijkt de opslagservice de hash van de inhoud die afkomstig is van de copy-source met deze headerwaarde. Houd er rekening mee dat deze MD5-hash niet wordt opgeslagen met de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (Ongeldig verzoek).
`x-ms-source-content-crc64`	Facultatief. Een CRC64-hash van de toevoegblokinhoud van de URI. Deze hash wordt gebruikt om de integriteit van het toevoegblok te controleren tijdens het transport van de gegevens van de URI. Wanneer u deze header opgeeft, vergelijkt de opslagservice de hash van de inhoud die afkomstig is van de copy-source met deze headerwaarde. Houd er rekening mee dat deze CRC64-hash niet wordt opgeslagen met de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (Ongeldig verzoek). Als zowel als `x-ms-source-content-md5x-ms-source-content-crc64` headers aanwezig zijn, mislukt de aanvraag met een 400 (Ongeldige aanvraag). Deze header wordt ondersteund in versie 2019-02-02 of hoger.
`x-ms-encryption-scope`	Facultatief. Geeft het versleutelingsbereik aan dat moet worden gebruikt om de broninhoud te versleutelen. Deze header wordt ondersteund in versie 2019-02-02 of 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`	Facultatief. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet 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.
`x-ms-blob-condition-maxsize`	Optionele voorwaardelijke header. De maximale lengte in bytes die is toegestaan voor de toevoegingsblob. Als de `Append Block From URL` bewerking ervoor zorgt dat de blob die limiet overschrijdt of als de blobgrootte al groter is dan de waarde die in deze header is opgegeven, mislukt de aanvraag met een 412 (voorwaarde mislukt).
`x-ms-blob-condition-appendpos`	Optionele voorwaardelijke header, alleen gebruikt voor de `Append Block from URL` bewerking. Een getal dat de bytevergelijking aangeeft die moet worden vergeleken. `Append Block from URL` Lukt alleen als de positie van de toevoeging gelijk is aan dit getal. Als dit niet het geval is, mislukt de aanvraag met een 412 (Precondition Failed).
`x-ms-file-request-intent`	Vereist als `x-ms-copy-source` de header een Azure-bestands-URL is en `x-ms-copy-source-authorization` de header een OAuth-token opgeeft. Acceptabele waarde is `backup`. Deze header geeft aan dat de `Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action` of `Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action` moeten worden verleend als ze zijn opgenomen in het RBAC-beleid dat is toegewezen aan de identiteit die is geautoriseerd met behulp van de `x-ms-copy-source-authorization`-header. Beschikbaar voor versie 2025-07-05 en later.

Deze bewerking ondersteunt het gebruik van aanvullende, voorwaardelijke headers om ervoor te zorgen dat de API alleen slaagt als aan een opgegeven voorwaarde wordt voldaan. Zie Voorwaardelijke headers opgeven voor Blob Storage-bewerkingen voor meer informatie.

Aanvraagheaders (door de klant verstrekte coderingssleutels)

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

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

Requestheaders (broncode-sleutels van klantverstrekte sleutels)

Vanaf versie 2026-02-06 kunnen de volgende headers worden opgegeven in een verzoek om een blob te kopiëren die is versleuteld met een door de klant verstrekte sleutel. Deze headers zijn alleen nodig wanneer de bronblob in Azure Storage is versleuteld met een door de klant verstrekte sleutel.

Voor deze functie konden klanten hun door de klant verstrekte sleutels alleen aan de clientzijde roteren door de blob met de oude sleutel te downloaden en opnieuw te uploaden met de nieuwe sleutel. Met deze nieuwe headers kunnen klanten nu een blob volledig opnieuw versleutelen aan de serverzijde. Klanten kunnen bijvoorbeeld specificeren key1 in de door de klant verstrekte bronsleutelheaders en key2 in de door de bestemmingsklant verstrekte key headers. Daarnaast kunnen klanten een blob ontsleutelen door alleen de door de klant verstrekte bronsleutelheaders toe te passen.

Header van het verzoek	Beschrijving
`x-ms-source-encryption-key`	Verplicht. De met Base64 gecodeerde AES-256-versleutelingssleutel.
`x-ms-source-encryption-key-sha256`	Verplicht. De met Base64 gecodeerde SHA256-hash van de versleutelingssleutel.
`x-ms-source-encryption-algorithm: AES256`	Verplicht. Hiermee geeft u het algoritme op dat moet worden gebruikt voor versleuteling. De waarde van deze header moet zijn `AES256`.

Inhoud van het verzoek

De aanvraagbody bevat de inhoud van het blok.

Voorbeeldaanvraag

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock  HTTP/1.1  

Request Headers:  
x-ms-version: 2018-11-09  
x-ms-date: <date>  
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-65535
x-ms-blob-condition-appendpos: 2097152  
x-ms-blob-condition-maxsize: 4194304  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0 
If-Match: "0x8CB172A360EC34B"

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

Antwoordheader	Beschrijving
`Etag`	De `ETag` bevat een waarde tussen aanhalingstekens. De client gebruikt de waarde om voorwaardelijke `PUT` bewerkingen uit te voeren met behulp van de `If-Match` aanvraagheader.
`Last-Modified`	De datum/tijd waarop de blob voor het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Weergave van datum/tijd-waarden in koptekstenvoor meer informatie. Elke schrijfbewerking op de blob (inclusief updates van de metagegevens of eigenschappen van de blob) wijzigt de tijd van de laatste wijziging van de blob.
`Content-MD5`	Deze header wordt geretourneerd, zodat de client kan controleren op integriteit van berichtinhoud. Blob Storage berekent de waarde van deze header. Het is niet noodzakelijkerwijs dezelfde waarde die is opgegeven in de aanvraagheaders. Voor versie 2019-02-02 of hoger wordt deze header alleen geretourneerd als de aanvraag deze header bevat.
`x-ms-content-crc64`	Voor versie 2019-02-02 of hoger. Deze header wordt geretourneerd, zodat de client kan controleren op integriteit van berichtinhoud. Blob Storage berekent de waarde van deze header. Het is niet noodzakelijkerwijs dezelfde waarde die is opgegeven in de aanvraagheaders. Deze header wordt geretourneerd wanneer de `x-ms-source-content-md5` header niet aanwezig is in de aanvraag.
`x-ms-request-id`	Deze header identificeert de aanvraag die is gemaakt en kan worden gebruikt voor het oplossen van problemen met de aanvraag.
`x-ms-version`	Geeft de versie van Blob Storage 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.
`Date`	Een UTC-datum/tijdwaarde die wordt gegenereerd door de service die het tijdstip aangeeft waarop het antwoord is gestart.
`x-ms-blob-append-offset`	Deze antwoordheader wordt alleen geretourneerd voor toevoegbewerkingen. Hiermee wordt de offset geretourneerd waarop het blok is doorgevoerd, in bytes.
`x-ms-blob-committed-block-count`	Het aantal vastgelegde blokken dat aanwezig is in de blob. U kunt dit gebruiken om te bepalen hoeveel extra bijlagen kunnen worden gedaan.
`x-ms-request-server-encrypted: true/false`	Versie 2015-12-11 of hoger. De waarde van deze header is ingesteld op `true` als de inhoud van de aanvraag is versleuteld met behulp van het opgegeven algoritme. Anders is de waarde ingesteld op `false`.
`x-ms-encryption-key-sha256`	Versie 2019-02-02 of hoger. Deze header wordt geretourneerd als voor de aanvraag een door de klant verstrekte sleutel voor versleuteling is gebruikt. De client kan er vervolgens voor zorgen dat de inhoud van het verzoek wordt versleuteld met behulp van de opgegeven sleutel.
`x-ms-encryption-scope`	Versie 2019-02-02 of hoger. Deze header wordt geretourneerd als de aanvraag een coderingsbereik gebruikte. De client kan er vervolgens voor zorgen dat de inhoud van de aanvraag wordt versleuteld met behulp van het versleutelingsbereik.

Voorbeeldantwoord

Response Status:  
HTTP/1.1 201 Created  

Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: <date>  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-blob-append-offset: 2097152  
x-ms-blob-committed–block-count: 1000

Autorisatie

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

De autorisatiegegevens in dit gedeelte zijn van toepassing op de bestemming van de kopie. Zie de details van de aanvraagheader x-ms-copy-sourcevoor meer informatie over het machtigen van de kopieerbron.

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.

Machtigingen

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Append Block From URL-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/add/action of Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
ingebouwde rol met minimale bevoegdheden:Inzender voor opslagblobgegevens

Zie Een Azure-rol toewijzen voor toegang tot blobgegevensvoor 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 door middel van Microsoft Entra-referenties en door de machtigingen die zijn opgegeven voor de SAS.

Voor het aanroepen van de Append Block From URL bewerking met behulp van een SAS-token dat is gedelegeerd aan een container of blobresource, is de machtiging Toevoegen (a) of Schrijven (w) vereist als onderdeel van het SAS-token voor gebruikersdelegering:

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.

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:

Operatie	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Blok toevoegen van URL	Klodder (b)	Voorwerp (o)	Toevoegen (a) of schrijven (w)

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

Opmerkingen

Append Block From URL Uploadt een blok naar het einde van een bestaande Toevoeg-BLOB. Het gegevensblok is onmiddellijk beschikbaar nadat de oproep op de server is geslaagd. Er zijn maximaal 50.000 toevoegingen toegestaan voor elke toevoegingsblob. Elk blok kan een andere grootte hebben.

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

Serviceversie	Maximale blokgrootte (via `Append Block From URL`)	Maximale blobgrootte
Versie 2022-11-02 en later	100 MiB (Voorbeeld)	Ongeveer 4,75 TiB (100 MiB × 50.000 blokken)
Versies eerder dan 2022-11-02	4 MiB	Ongeveer 195 gibibyte (GiB) (4 MiB × 50.000 blokken)

In versie 2020-10-02 en hoger wordt Microsoft Entra-ID-autorisatie ondersteund voor de bron van de kopieerbewerking.

Append Block From URL Lukt alleen als de blob al bestaat.

Blobs die zijn geüpload met behulp van Append Block From URL maken geen blok-id's beschikbaar, dus u kunt Blokkeerlijst ophalen niet aanroepen tegen een toevoegblob. Dit resulteert in een fout.

U kunt de volgende optionele, voorwaardelijke koppen opgeven voor de aanvraag:

x-ms-blob-condition-appendpos: U kunt deze header instellen op een byte-offset waarbij de client verwacht het blok toe te voegen. De aanvraag slaagt alleen als de huidige offset overeenkomt met de door de klant opgegeven offset. Anders mislukt de aanvraag met foutcode 412 (Voorvoorwaarde mislukt).

Clients die één schrijver gebruiken, kunnen deze header gebruiken om te bepalen of een Append Block From URL bewerking is geslaagd, ondanks een netwerkfout.
x-ms-blob-condition-maxsize: Clients kunnen deze header gebruiken om ervoor te zorgen dat toevoegbewerkingen de blobgrootte niet vergroten tot boven een verwachte maximale grootte in bytes. Als de voorwaarde mislukt, mislukt de aanvraag met foutcode 412 (Voorvoorwaarde mislukt).

Als u probeert een blok te uploaden dat groter is dan de toegestane grootte, retourneert de service HTTP-foutcode 413 (Request Entity Too Large). De service retourneert ook aanvullende informatie over de fout in het antwoord, inclusief de maximale blokgrootte die is toegestaan in bytes. Als u meer dan 50.000 blokken probeert te uploaden, retourneert de service foutcode 409 (Conflict).

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 foutcode 412 (Voorvoorwaarde mislukt). Als de client een lease-id opgeeft, maar de blob geen actieve lease heeft, retourneert de service foutcode 412.

Als u een bestaande blok-blob of pagina-blob aanroept Append Block From URL , retourneert de service foutcode 409 (conflict). Als u een niet-bestaande blob aanroept Append Block From URL , retourneert de service foutcode 404 (Niet gevonden).

Vermijd dubbele of vertraagde bijlagen

In een scenario met één schrijver kan de client dubbele toevoegingen of vertraagde schrijfbewerkingen voorkomen door de x-ms-blob-condition-appendpos voorwaardelijke koptekst te gebruiken om de huidige offset te controleren. De klant kan ook duplicaten of vertragingen voorkomen door de ETag voorwaardelijke controle te gebruiken.If-Match

In een scenario met meerdere schrijvers kan elke client voorwaardelijke headers gebruiken. Dit is misschien niet optimaal voor de prestaties. Voor de hoogste gelijktijdige doorvoer van toevoegingen moeten toepassingen redundante toevoegingen en vertraagde toevoegingen in hun toepassingslaag verwerken. Toepassingen kunnen bijvoorbeeld epochs of volgnummers toevoegen aan de gegevens die worden toegevoegd.

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

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 Append Block From URL aanvragen op basis van het type opslagaccount:

Operatie	Type opslagaccount	Factureringscategorie
Blokkeren van URL toevoegen (bestemmingsaccount¹)	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Schrijfbewerkingen
Blok toevoegen van URL (bronaccount²)	Premium blok-blob Standaard algemeen gebruik v2 Standaard algemeen gebruik v1	Leesbewerkingen

¹Het bestemmingsaccount wordt in rekening gebracht voor één transactie om het schrijven te starten.
^{Arabisch cijfer}Het bronaccount voert één transactie uit voor elke leesaanvraag naar de bron.

Last updated on 2026-01-22

Delen via