Pagina zetten

De Put Page operatie schrijft een reeks pagina's naar een paginablob.

Aanvraag

U kunt de Put Page 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=page`	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=page`	HTTP/1.1

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

URI Parameters

U kunt de volgende extra parameters opgeven op de request URI:

Kenmerk	Description
`timeout`	Optional. De `timeout` parameter wordt uitgedrukt in seconden. Voor meer informatie, zie Time-outs instellen voor Blob-serviceoperaties.

Headers aanvragen

De vereiste en optionele aanvraagheaders worden beschreven in de volgende tabel:

Header van het verzoek	Description
`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 verzoeken. Hiermee geeft u de versie van de bewerking die moet worden gebruikt voor deze aanvraag. Zie Versiebeheer voor de Azure Storage-services voor meer informatie.
`Range`	`Range` Of `x-ms-range` is vereist. Specificeert het bereik van bytes dat als pagina moet worden geschreven. Zowel het begin als het einde van het bereik moet worden opgegeven. Deze header wordt gedefinieerd door de HTTP/1.1-protocolspecificatie. Voor een pagina-update kan het paginabereik tot 4 MiB zijn. Voor een pagina-clear operatie kan het paginabereik net zo groot zijn als de waarde van de volledige grootte van de blob. Omdat pagina's uitgelijnd moeten zijn met 512-byte grenzen, moet de startoffset een modulus van 512 hebben en de eindoffset een modulus van 512 –1. Voorbeelden van geldige bytebereiken zijn 0-511, 512-1023, enzovoort. Blob Storage accepteert slechts één bytebereik voor de `Range` header, en dat bytebereik moet worden gespecificeerd in het volgende formaat: `bytes=startByte-endByte`. Als zowel `Range` als `x-ms-range` zijn gespecificeerd, gebruikt de dienst de waarde van `x-ms-range`. Voor meer informatie, zie Specificeer de rangeheader voor Blob service-operaties.
`x-ms-range`	`Range` Of `x-ms-range` is vereist. Specificeert het bereik van bytes dat als pagina moet worden geschreven. Zowel het begin als het einde van het bereik moet worden opgegeven. Deze header wordt gedefinieerd door de HTTP/1.1-protocolspecificatie. Voor een pagina-update kan het paginabereik tot wel 4 MiB groot zijn. Voor een duidelijke bewerking van een pagina kan het paginabereik de waarde van de volledige grootte van de blob hebben. Omdat pagina's uitgelijnd moeten zijn met 512-byte grenzen, moet de startoffset een modulus van 512 hebben en de eindoffset een modulus van 512 – 1. Voorbeelden van geldige bytebereiken zijn 0-511, 512-1023, enzovoort. Blob Storage accepteert slechts één bytebereik voor de `x-ms-range` header, en dat bytebereik moet worden gespecificeerd in het volgende formaat: `bytes=startByte-endByte`. Als zowel `Range` als `x-ms-range` zijn gespecificeerd, gebruikt de dienst de waarde van `x-ms-range`. Zie Specificeer de range-header voor Blob-serviceoperaties voor meer informatie.
`Content-Length`	Verplicht. Specificeert het aantal bytes dat in de request body wordt verzonden. Wanneer de `x-ms-page-write` header is ingesteld op `clear`, moet de waarde van deze header worden gezet op `0`.
`Content-MD5`	Optional. Een MD5-hash van de pagina-inhoud. Deze hash wordt gebruikt om de integriteit van de pagina tijdens transport te verifiëren. Wanneer deze header wordt gespecificeerd, vergelijkt de opslagservice de hash van de inhoud die is aangekomen, met deze headerwaarde. <br / >Opmerking: Deze MD5-hash wordt niet opgeslagen bij de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (Ongeldig verzoek).
`x-ms-content-crc64`	Optional. Een CRC64-hash van de pagina-inhoud. Deze hash wordt gebruikt om de integriteit van de pagina tijdens transport te verifiëren. Wanneer deze header wordt gespecificeerd, vergelijkt de opslagservice de hash van de inhoud die is aangekomen, met deze headerwaarde. Opmerking: Deze CRC64-hash wordt niet samen met de blob opgeslagen. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (Ongeldig verzoek). Als zowel de `Content-MD5` and-headers `x-ms-content-crc64` aanwezig zijn, faalt het verzoek met een 400 (Bad Request). Deze header wordt ondersteund in versie 2019-02-02 en later.
`x-ms-page-write: {update ¦ clear}`	Verplicht. U kunt een van de volgende opties specificeren: - `Update`: Schrijft de bytes die door het verzoeklichaam zijn gespecificeerd in het opgegeven bereik. De `Range` en-headers `Content-Length` moeten overeenkomen om de update uit te voeren. - `Clear`: Maakt het opgegeven bereik leeg en maakt de ruimte vrij die voor opslag voor dat bereik wordt gebruikt. Om een bereik te wissen, zet u de `Content-Length` header op `0`, en zet u de `Range` header op een waarde die het bereik aangeeft tot de maximale blobgrootte.
`x-ms-encryption-scope`	Optional. Geeft het versleutelingsbereik aan dat moet worden gebruikt om de inhoud van de aanvraag te versleutelen. Deze header wordt ondersteund in versie 2019-02-02 en later.
`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-if-sequence-number-le: <num>`	Optional. Als het volgnummer van de blob kleiner is dan of gelijk aan de opgegeven waarde, gaat het verzoek door. Anders faalt het met de SequenceNumberConditionNotMet-fout (HTTP-statuscode 412 – Precondition Failed).
`x-ms-if-sequence-number-lt: <num>`	Optional. Als het volgnummer van de blob kleiner is dan de opgegeven waarde, gaat het verzoek door. Anders faalt het met de fout SequenceNumberConditionNotMet (HTTP-statuscode 412 – Precondition Failed).
`x-ms-if-sequence-number-eq: <num>`	Optional. Als het volgnummer van de blob gelijk is aan de gespecificeerde waarde, gaat het verzoek door. Anders faalt het met de fout SequenceNumberConditionNotMet (HTTP-statuscode 412 – Precondition Failed).
`If-Modified-Since`	Optional. Een `DateTime` waarde. Specificeer deze conditionele header om de pagina alleen te schrijven als de blob is aangepast sinds de opgegeven datum/tijd. Als de blob niet is gewijzigd, geeft Blob Storage statuscode 412 (Precondition Failed) terug.
`If-Unmodified-Since`	Optional. Een `DateTime` waarde. Specificeer deze conditionele header om de pagina alleen te schrijven als de blob sinds de opgegeven datum/tijd niet is gewijzigd. Als de blob is gewijzigd, geeft Blob Storage statuscode 412 (Precondition Failed) terug.
`If-Match`	Optional. Een ETag-waarde. Specificeer een ETag-waarde voor deze conditionele header om de pagina alleen te schrijven als de ETag-waarde van de blob overeenkomt met de gespecificeerde waarde. Als de waarden niet overeenkomen, geeft Blob Storage statuscode 412 (Precondition Failed) terug.
`If-None-Match`	Optional. Een ETag-waarde. Specificeer een ETag-waarde voor deze conditionele header om de pagina alleen te schrijven als de ETag-waarde van de blob niet overeenkomt met de gespecificeerde waarde. Als de waarden identiek zijn, geeft Blob Storage statuscode 412 (Precondition Failed) terug.
`x-ms-client-request-id`	Optional. Biedt een door de client gegenereerde, ondoorzichtige waarde met een tekenlimiet van 1 kibibyte (KiB) die wordt vastgelegd in de logboeken wanneer logboekregistratie 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. Zie Azure Blob Storage bewaken voor meer informatie.

Deze operatie ondersteunt ook het gebruik van conditionele headers om de operatie alleen uit te voeren als aan een gespecificeerde voorwaarde is voldaan. Voor meer informatie, zie Specificeer conditionele headers voor Blob-serviceoperaties.

Request-headers (door de klant verstrekte encryptiesleutels)

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	Description
`x-ms-encryption-key`	Verplicht. De door Base64 gecodeerde AES-256 encryptiesleutel.
`x-ms-encryption-key-sha256`	Verplicht. De door Base64 gecodeerde SHA256-hash van de encryptiesleutel.
`x-ms-encryption-algorithm: AES256`	Verplicht. Specificeert het algoritme dat voor encryptie moet worden gebruikt. De waarde van deze header moet zijn `AES256`.

Verzoekheaders (gestructureerde body)

Vanaf versie 2025-01-05 kunnen de volgende headers op het verzoek worden gespecificeerd om gebruik te maken van het gestructureerde lichaamsformaat.

Header van het verzoek	Description
`Content-Length`	Verplicht. Moet de lengte van het gecodeerde verzoek zijn (niet alleen de lengte van de pagina-inhoud). Als de waarde van de header niet overeenkomt met de verwachte lengte van het gecodeerde verzoek, faalt de bewerking met foutcode 400 (Bad Request).
`x-ms-structured-body`	Verplicht. Moet worden opgenomen als het berichtformaat is gestructureerd. De waarde van deze header bevat de versie en eigenschappen van het berichtschema. Momenteel wordt alleen de waarde ondersteund , `XSM/1.0; properties=crc64`wat aangeeft dat het verzoek crc64-checksumsegmenten gebruikt in het gecodeerde bericht. Als de waarde hier niet overeenkomt, faalt de bewerking met foutcode 400 (Bad Request). Het verzoek zal ook falen als de inhoud die in het verzoek wordt geleverd niet overeenkomt met de opgegeven checksum voor een bepaald segment met foutcode 400 (Bad Request).
`x-ms-structured-content-length`	Verplicht. Moet worden opgenomen als het berichtformaat is gestructureerd. De waarde van deze header is de lengte van de paginainhoud en zal altijd kleiner zijn dan de `Content-Length` headerwaarde vanwege berichtcodering. Als de waarde van de header niet overeenkomt met de lengte van de blokinhoud die in het verzoek wordt gegeven, mislukt de operatie met foutcode 400 (Bad Request).

Inhoud van het verzoek

De verzoektekst bevat de inhoud van de pagina.

Voorbeeldverzoek: Update-bytebereik

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:  
x-ms-page-write: update  
x-ms-date: Fri, 16 Sep 2011 22:15:50 GMT  
x-ms-version: 2011-08-18  
x-ms-range: bytes=0-65535  
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=  
Content-Length: 65536

Voorbeeldverzoek: Clear byte bereik

  
Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1  
  
Request Headers:  
Range: bytes=1024-2048  
x-ms-page-write: clear  
x-ms-date: Sun, 25 Sep 2011 23:37:35 GMT  
x-ms-version: 2011-08-18  
Authorization: SharedKey myaccount:4KdWDiTdA9HmIF9+WF/8WfYOpUrFhieGIT7f0av+GEI=

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

Syntaxis	Description
`ETag`	De ETag voor de blob. Als de aanvraagversie 2011-08-18 en later is, wordt de ETag-waarde tussen aanhalingstekens geplaatst. De ETag kan worden gebruikt om een conditionele `Put Page` bewerking uit te voeren door de waarde voor de `If-Match` of `If-None-Match` request-header te specificeren.
`Last-Modified`	De datum en tijd waarop de blob voor het laatst is aangepast. Het datumformaat volgt RFC 1123. Voor meer informatie, zie Datum-/tijdwaarden weergeven in headers. Elke schrijfoperatie op de blob, inclusief updates van de metadata of eigenschappen van de blob, verandert de laatst gewijzigde tijd van de blob.
`Content-MD5`	Deze header wordt geretourneerd, zodat de client kan controleren op integriteit van berichtinhoud. De waarde van deze header wordt berekend door Blob Storage. Het is niet per se hetzelfde als de waarde die in de requestheaders wordt gespecificeerd. 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 of later wordt deze header teruggegeven zodat de client kan controleren op de integriteit van de berichtinhoud. De waarde van deze header wordt berekend door Blob Storage. Het is niet per se hetzelfde als de waarde die in de requestheaders wordt gespecificeerd. Deze header wordt teruggegeven wanneer `Content-MD5` de header niet aanwezig is in het verzoek.
`x-ms-blob-sequence-number`	Het huidige volgnummer voor de pagina-blob.
`x-ms-request-id`	Identificeert uniek het verzoek dat is gedaan en kan worden gebruikt om het verzoek te troubleshooten. Zie Problemen met API-bewerkingen oplossenvoor meer informatie.
`x-ms-version`	Geeft de Blob-serviceversie aan die is gebruikt om het verzoek 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, wat de tijd aangeeft waarop het antwoord 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 later. Teruggestuurd als het verzoek een door de klant verstrekte sleutel gebruikte voor encryptie, 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 later. Teruggestuurd als het verzoek een encryptiescope gebruikte, zodat de client kan garanderen dat de inhoud van het verzoek succesvol is versleuteld door gebruik te maken van de encryptiescope.
`x-ms-client-request-id`	Kan worden gebruikt om problemen met verzoeken 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.
`x-ms-structured-body`	Teruggestuurd als het verzoek als een gestructureerd body request is verwerkt. De waarde van deze header is gelijk aan de waarde die in het verzoek wordt verzonden, die momenteel moet zijn `XSM/1.0; properties=crc64`.

Antwoordlichaam

Geen.

Voorbeeldantwoord

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 22:33:35 GMT  
ETag: "0x8CB171BA9E94B0B"  
Last-Modified: Sun, 25 Sep 2011 12:13:31 GMT  
x-ms-version: 2011-08-18  
x-ms-blob-sequence-number: 0  
Content-Length: 0  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Authorization

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

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.

Permissions

Hieronder vindt u de RBAC-actie die nodig is voor een Microsoft Entra-gebruiker, groep, beheerde identiteit of service-principal om de Put Page-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/write
Ingebouwde rol met minste bevoegdheden:Storage Blob Data Contributor

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, 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 met Microsoft Entra-referenties en ook met de machtigingen die zijn opgegeven voor de SAS.

Het aanroepen van de Put Page operatie met een SAS-token dat is gedelegeerd aan een container of blobresource vereist de Write (w)- toestemming als onderdeel van het gebruikersdelegatie-SAS-token.

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.

Het aanroepen van de Put Page operatie met een SAS-token dat is gedelegeerd aan een container of blobresource vereist de Write (w) -toestemming 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 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:

Operation	Ondertekende service	Ondertekend resourcetype	Ondertekende machtiging
Pagina zetten	Klodder (b)	Voorwerp (o)	Schrijf (w)

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

Opmerkingen

De Put Page operatie schrijft een reeks pagina's naar een paginablob. Deze bewerking kan alleen worden aangeroepen op een bestaande page blob. Het kan niet worden aangeroepen om een nieuwe page blob aan te maken, noch kan het worden aangeroepen op een block blob. Aanroepen Put Page met een blobnaam die momenteel niet bestaat levert HTTP-statuscode 404 (Niet gevonden) terug.

Om een nieuwe page blob aan te maken, roep Put Blob aan en geef het type blob aan dat als page blob moet worden aangemaakt. Een paginablob kan tot 8 TiB groot zijn.

Als de blob een actieve lease heeft, moet de client een geldige lease-ID opgeven op het verzoek om een pagina te schrijven.

Pagina-updateoperaties

Aanroepen Put Page met de optie voert Update een in-place write uit op de gespecificeerde paginablob. Alle inhoud op de opgegeven pagina wordt overschreven met de update.

Belangrijk

Als de server uitvalt of je verbinding wordt gesloten tijdens een Put Page bewerking, kan de pagina wel of niet zijn bijgewerkt. Daarom moet je de update opnieuw proberen totdat je een reactie ontvangt die aangeeft dat je succesvol bent.

Elke reeks pagina's die wordt ingediend Put Page voor een update-operatie kan tot 4 MiB groot zijn. Het begin- en eindbereik van de pagina moeten worden uitgelijnd met 512-byte grenzen. Als je probeert een reeks pagina's te uploaden die groter is dan 4 MiB, geeft de dienst statuscode 413 (Request Entity Too Large) terug.

Pagina-clear operaties

Aanroepen Put Page met de Clear optie geeft de opslagruimte vrij die door de opgegeven pagina wordt gebruikt. Pagina's die zijn gewist, worden niet langer bijgehouden als onderdeel van de page blob.

Pagina's die zijn geleegd, worden niet langer belast met het opslagaccount, omdat hun opslagbronnen zijn vrijgegeven. De enige uitzondering hierop is als er al snapshots van de page blob zijn. Pagina's in snapshots zijn belast als diezelfde pagina's niet langer bestaan als onderdeel van de bronblob.

Beheer gelijktijdige kwesties

Blob Storage verwerkt gelijktijdige schrijfopdrachten naar overlappende pagina's achtereenvolgend. Dat wil zeggen, de laatste pagina die door de service wordt verwerkt, bepaalt de inhoud van de blob. Daarom moet de client schrijfopdrachten naar overlappende pagina's afhandelen door gebruik te maken van een of meer van de volgende benaderingen, om de integriteit van de inhoud van de blob te waarborgen:

Je kunt de waarde van de Last-Modified responsheader controleren voor elke succesvolle oproep naar Put Page. De volgorde van antwoorden die vanuit Blob Storage worden teruggestuurd, komt niet per se overeen met de volgorde waarin ze door de service zijn uitgevoerd. Maar de waarde van Last-Modified geeft altijd de volgorde aan waarin de dienst de verzoeken verwerkte.
Je kunt updates voorwaardelijk uitvoeren op basis van de ETag of de laatste gewijzigde tijd van de blob met behulp van optimistische gelijktijdigheid. Deze aanpak werkt goed als het aantal gelijktijdige schrijfbewerkingen relatief laag is. Gebruik hiervoor de conditionele verzoekheaders If-Match, If-None-Match, If-Modified-Since, en If-Unmodified-Since voor dit doel.
Je kunt Lease Blob aanroepen om de blob voor een minuut te vergrendelen tegen andere schrijfopdrachten, of langer als de lease wordt verlengd.
Je kunt het sequentienummer van de blob gebruiken om ervoor te zorgen dat het opnieuw proberen van een verzoek waarop geen reactie was, niet resulteert in gelijktijdige updates. Deze aanpak is mogelijk het beste voor klanten die een hoge doorvoer nodig hebben voor pagina-schrijfopdrachten. Dit wordt in detail beschreven in de volgende sectie.

Gebruik het pagina-blob-volgnummer om verzoeken opnieuw te proberen

Wanneer een oproep om te Put Page time-out is of geen antwoord oplevert, is er geen manier om met zekerheid te weten of het verzoek is geslaagd. Je moet het verzoek dus opnieuw proberen, maar vanwege de gedistribueerde aard van de Azure-opslagservices is het mogelijk dat het oorspronkelijke verzoek wordt verwerkt nadat het opnieuw geprobeerde verzoek is geslaagd. Het vertraagde oorspronkelijke verzoek kan andere updates overschrijven en een onverwacht resultaat opleveren. De volgende reeks illustreert hoe dit zou kunnen gebeuren:

Een Put Page verzoek om waarde "X" op pagina 0 te schrijven loopt uit of geeft geen antwoord terug.
Een hernieuwd verzoek om waarde "X" naar pagina 0 te schrijven slaagt.
Een verzoek om waarde "Y" op pagina 0 te schrijven slaagt.
Het oorspronkelijke verzoek slaagt en schrijft waarde "X" naar pagina 0.
Het lezen van pagina 0 levert waarde "X" terug, terwijl de klant op dat moment waarde "Y" verwachtte.

Dit soort conflicten kan optreden wanneer het oorspronkelijke verzoek geen statuscode teruggeeft van 100 tot 499, of 503 (Server Busy). Als een van deze statuscodes wordt teruggestuurd, kun je zeker weten of het verzoek is geslaagd of mislukt. Maar als de dienst een statuscode buiten dit bereik teruggeeft, is er geen manier om de status van het oorspronkelijke verzoek te weten.

Om dit soort conflicten te voorkomen, kun je het volgnummer van de page blob gebruiken om ervoor te zorgen dat wanneer je een verzoek opnieuw probeert, het oorspronkelijke verzoek niet slaagt. Om dit te doen, moet je het volgnummer verhogen voordat je het oorspronkelijke verzoek opnieuw probeert. Je kunt dan de conditionele volgnummerheaders gebruiken om ervoor te zorgen dat het verzoek faalt als het volgnummer niet overeenkomt met het verwachte volgnummer. De volgende reeks illustreert deze benadering:

De client maakt een page blob aan met Put Blob en stelt het volgnummer in op 0.
Een Put Page verzoek om waarde "X" op pagina 0 te schrijven met de if-sequence-number-lt header op time-out of 1 geeft geen antwoord terug.
De client roept Set Blob Properties aan om het volgnummer bij te werken naar 1.
Een hernieuwd verzoek om waarde "X" naar pagina 0 te schrijven met if-sequence-number-lt gezet op 2 slaagt.
Een verzoek om waarde "Y" naar pagina 0 te schrijven met if-sequence-number-lt een set op 2 slaagt.
Het oorspronkelijke verzoek wordt uiteindelijk verwerkt, maar faalt omdat het de voorwaarde specificeert dat het volgnummer kleiner dan 1 moet zijn (dat wil zeggen, de if-sequence-num-lt header is ingesteld op 1). De fout is SequenceNumberNotMet (HTTP-statuscode 412 – Precondition Failed).
Het lezen van pagina 0 geeft de verwachte waarde van "Y" terug.

Zie ook

Aanvragen voor Azure Storage autoriseren
status en foutcodes
Stel time-outs in voor Blob-serviceoperaties

Last updated on 2026-01-22

Delen via