Pagina van URL plaatsen

Artikel
05/15/2024

Met Put Page From URL de bewerking wordt een bereik van pagina's naar een pagina-blob geschreven waar de inhoud wordt gelezen vanuit een URL. Deze API is beschikbaar vanaf versie 2018-11-09.

Aanvraag

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

Geëmuleerde opslagservice-URI

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=page`	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:

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.
`Range`	`x-ms-range` Of `Range` is vereist. Hiermee geeft u het bereik van bytes moet worden geschreven als een pagina. Zowel het begin als het einde van het bereik moeten worden opgegeven. Deze header wordt gedefinieerd door de http/1.1-protocolspecificatie. Voor een pagina-updatebewerking kan het paginabereik maximaal 4 MiB groot zijn. Omdat pagina's moeten worden uitgelijnd met grenzen van 512 bytes, moet de begin offset een modulus van 512 zijn en de eind offset een modulus van 512 – 1. Voorbeelden van geldige bytebereiken zijn 0-511, 512-1023, enzovoort. De Blob-service accepteert slechts één bytebereik voor de `Range` header en het bytebereik moet worden opgegeven in de volgende indeling: `bytes=startByte-endByte`. Als beide `Range` en `x-ms-range` zijn opgegeven, gebruikt de service de waarde van `x-ms-range`. Zie De bereikheader opgeven voor blobservicebewerkingen voor meer informatie.
`x-ms-range`	`x-ms-range` Of `Range` is vereist. Hiermee geeft u het bereik van bytes moet worden geschreven als een pagina. Zowel het begin als het einde van het bereik moeten worden opgegeven. Deze header wordt gedefinieerd door de http/1.1-protocolspecificatie. Het paginabereik kan maximaal 4 MiB groot zijn. Omdat pagina's moeten worden uitgelijnd met grenzen van 512 bytes, moet de begin offset een modulus van 512 zijn en de eind offset een modulus van 512 – 1. Voorbeelden van geldige bytebereiken zijn 0-511, 512-1023, enzovoort. De Blob-service accepteert slechts één bytebereik voor de `x-ms-range` header en het bytebereik moet worden opgegeven in de volgende indeling: `bytes=startByte-endByte`. Als beide `Range` en `x-ms-range` zijn opgegeven, gebruikt de service de waarde van `x-ms-range`. Zie De bereikheader opgeven voor blobservicebewerkingen voor meer informatie.
`Content-Length`	Vereist. Hiermee geeft u het aantal bytes dat wordt verzonden in de aanvraagbody. De waarde van deze koptekst moet worden ingesteld op nul. Wanneer de lengte niet nul is, mislukt de bewerking met de statuscode 400 (Ongeldige aanvraag).
`x-ms-copy-source:name`	Vereist. Hiermee geeft u de URL van de bron-blob op. De waarde kan een URL van maximaal 2 KiB zijn 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 worden 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 bronobject-URL's: - `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>`	Optioneel. Hiermee geeft u het autorisatieschema en de handtekening voor de kopieerbron op. Zie Aanvragen autoriseren voor Azure Storage voor meer informatie. Alleen een schemadrager wordt ondersteund voor Microsoft Entra. Deze header wordt ondersteund in versie 2020-10-02 en hoger.
`x-ms-source-range`	Uploadt de bytes van de blob in de bron-URL in het opgegeven bereik. Zowel het begin als het einde van het bereik moeten worden opgegeven. Deze header wordt gedefinieerd door de http/1.1-protocolspecificatie. Het paginabereik kan maximaal 4 MiB groot zijn. De Blob-service accepteert slechts één bytebereik voor de `x-ms-source-range` header en het bytebereik moet worden opgegeven in de volgende indeling: `bytes=startByte-endByte`. Zie De bereikheader opgeven voor blobservicebewerkingen voor meer informatie.
`x-ms-source-content-md5`	Optioneel. Een MD5-hash van de pagina-inhoud van de URI. Deze hash wordt gebruikt om de integriteit van de pagina te controleren tijdens het transport van de gegevens uit de URI. Wanneer deze header is opgegeven, vergelijkt de opslagservice de hash van de inhoud die afkomstig is van de copy-source met deze headerwaarde. Opmerking: deze MD5-hash wordt niet opgeslagen met de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (ongeldige aanvraag).
`x-ms-source-content-crc64`	Optioneel. Een CRC64-hash van de pagina-inhoud van de URI. Deze hash wordt gebruikt om de integriteit van de pagina te controleren tijdens het transport van de gegevens uit de URI. Wanneer deze header is opgegeven, vergelijkt de opslagservice de hash van de inhoud die afkomstig is van de copy-source met deze headerwaarde. Opmerking: deze CRC64-hash wordt niet opgeslagen met de blob. Als de twee hashes niet overeenkomen, mislukt de bewerking met foutcode 400 (ongeldige aanvraag). Als zowel `x-ms-source-content-md5` als `x-ms-source-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-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>`	Optioneel. Als het volgnummer van de blob kleiner is dan of gelijk is aan de opgegeven waarde, wordt de aanvraag voortgezet. Anders mislukt het met de SequenceNumberConditionNotMet-fout (HTTP-statuscode 412 – Voorwaarde mislukt).
`x-ms-if-sequence-number-lt: <num>`	Optioneel. Als het volgnummer van de blob kleiner is dan de opgegeven waarde, gaat de aanvraag door. Anders mislukt het met de sequenceNumberConditionNotMet-fout (HTTP-statuscode 412 – Voorwaarde mislukt).
`x-ms-if-sequence-number-eq: <num>`	Optioneel. Als het volgnummer van de blob gelijk is aan de opgegeven waarde, gaat de aanvraag door. Anders mislukt het met de sequenceNumberConditionNotMet-fout (HTTP-statuscode 412 – Voorwaarde mislukt).
`If-Modified-Since`	Optioneel. Een `DateTime` waarde. Geef deze voorwaardelijke koptekst op om de pagina alleen te schrijven als de blob is gewijzigd sinds de opgegeven datum/tijd. Als de blob niet is gewijzigd, retourneert de Blob-service statuscode 412 (Voorwaarde mislukt).
`If-Unmodified-Since`	Optioneel. Een `DateTime` waarde. Geef deze voorwaardelijke koptekst op om de pagina alleen te schrijven als de blob sinds de opgegeven datum/tijd niet is gewijzigd. Als de blob is gewijzigd, retourneert de Blob-service statuscode 412 (Voorwaarde mislukt).
`If-Match`	Optioneel. Een ETag-waarde. Geef een ETag-waarde op voor deze voorwaardelijke header om de pagina alleen te schrijven als de ETag-waarde van de blob overeenkomt met de opgegeven waarde. Als de waarden niet overeenkomen, retourneert de Blob-service statuscode 412 (Voorwaarde mislukt).
`If-None-Match`	Optioneel. Een ETag-waarde. Geef een ETag-waarde op voor deze voorwaardelijke header om de pagina alleen te schrijven als de ETag-waarde van de blob niet overeenkomt met de opgegeven waarde. Als de waarden identiek zijn, retourneert de Blob-service statuscode 412 (Voorwaarde mislukt).
`x-ms-encryption-scope`	Optioneel. Geeft het versleutelingsbereik aan dat moet worden gebruikt om de broninhoud te versleutelen. Deze header wordt ondersteund in versie 2019-02-02 en hoger.
`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 blobservicebewerkingen voor meer informatie.

Aanvraagheaders (door de klant verstrekte versleutelingssleutels)

Vanaf versie 2019-02-02 kunnen de volgende headers worden opgegeven in de aanvraag om een blob te versleutelen die is versleuteld met een door de klant verstrekte 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

De aanvraagtekst bevat de inhoud van de pagina.

Voorbeeldaanvraag

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

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.

Syntax	Description
`ETag`	De ETag voor de blob. Als de aanvraagversie 2011-08-18 of hoger is, staat de ETag-waarde tussen aanhalingstekens. De ETag kan worden gebruikt om een voorwaardelijke `Put Page From URL` bewerking uit te voeren door de waarde ervan op te geven voor de `If-Match` aanvraagheader of `If-None-Match` .
`Last-Modified`	De datum en tijd waarop de blob het laatst is gewijzigd. De datumnotatie volgt RFC 1123. Zie Datum-/tijdwaarden weergeven in kopteksten voor meer informatie. Elke schrijfbewerking op de blob, inclusief updates van de metagegevens of eigenschappen van de blob, verandert de laatste wijzigingstijd van de blob.
`Content-MD5`	Geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. De waarde van deze header wordt berekend door de Blob-service. Dit is niet noodzakelijkerwijs hetzelfde als de waarde die is opgegeven in de aanvraagheaders. Voor versie 2019-02-02 of hoger wordt deze header alleen geretourneerd wanneer de aanvraag deze header heeft.
`x-ms-content-crc64`	Voor versie 2019-02-02 of hoger. Geretourneerd, zodat de client de integriteit van de berichtinhoud kan controleren. De waarde van deze header wordt berekend door de Blob-service. Dit is niet noodzakelijkerwijs hetzelfde als de waarde die is opgegeven in de aanvraagheaders. Deze header wordt geretourneerd wanneer `x-ms-source-content-md5` de header niet aanwezig is in de aanvraag.
`x-ms-blob-sequence-number`	Het huidige volgnummer voor de pagina-blob.
`x-ms-request-id`	Identificeert op unieke wijze de aanvraag die is gedaan en deze 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 blobserviceversie 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/tijd-waarde die wordt gegenereerd door de service, die de tijd aangeeft waarop 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, en `false` anders.
`x-ms-encryption-key-sha256`	Versie 2019-02-02 en hoger. Wordt geretourneerd als de aanvraag een door de klant verstrekte sleutel 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. 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-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.

Hoofdtekst van de reactie

Geen.

Voorbeeldantwoord

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
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

Autorisatie

Autorisatie is vereist bij het aanroepen van een bewerking voor gegevenstoegang in Azure Storage. U kunt de Put Page From URL 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 beheerde Azure-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 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 Put Page From URL 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 Page From URL 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 sleutel van het opslagaccount, die 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 gedeelde sleuteltoegang 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 gebruikersdelegatie

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 Page From URL 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 SAS-token voor gebruikersdelegatie.

Zie een SAS voor gebruikersdelegatie Creatie 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 de toegang tot een resource in één Azure Storage-service, zoals blobopslag.

Voor het aanroepen van de Put Page From URL 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 Creatie 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
Pagina van URL plaatsen	Blob (b)	Object (o)	Schrijven (w)

Zie Creatie een account-SAS Creatie voor meer informatie over de account-SAS.

Opmerkingen

Met de Put Page From URL bewerking wordt een bereik van pagina's naar een pagina-blob geschreven. Deze bewerking kan alleen worden aangeroepen op een bestaande pagina-blob. Het kan niet worden aangeroepen om een nieuwe pagina-blob te maken en kan ook niet worden aangeroepen op een blok-blob. Als u aanroept Put Page From URL met een blobnaam die momenteel niet bestaat, wordt de BlobNotFound-fout (HTTP-statuscode 404 – Niet gevonden) geretourneerd.

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

Als u een nieuwe pagina-blob wilt maken, roept u Put Blob aan en geeft u het type blob op dat moet worden gemaakt als een pagina-blob. Een pagina-blob kan maximaal 8 TiB groot zijn.

Als de blob een actieve lease heeft, moet de client een geldige lease-id opgeven voor de aanvraag om een pagina te schrijven.

Bewerkingen voor pagina-updates

Aanroepen Put Page From URL voert een in-place schrijfbewerking uit op de opgegeven pagina-blob. Alle inhoud op de opgegeven pagina wordt overschreven met de update.

Belangrijk

Als er een time-out optreedt voor de server of als de verbinding wordt gesloten tijdens een Put Page From URL, is de pagina mogelijk wel of niet bijgewerkt. Daarom moet u de update opnieuw uitvoeren totdat u een antwoord ontvangt dat aangeeft dat het is gelukt.

Elk paginabereik dat wordt verzonden met Put Page From URL voor een updatebewerking, kan maximaal 4 MiB groot zijn. Het begin- en eindbereik van de pagina moeten worden uitgelijnd met grenzen van 512 bytes. Als u probeert een bereik van pagina's te uploaden dat groter is dan 4 MiB, retourneert de service statuscode 413 (Aanvraagentiteit is te groot).

Gelijktijdigheidsproblemen beheren

De Blob-service verwerkt gelijktijdige schrijfbewerkingen naar overlappende pagina's opeenvolgend. Dat wil gezegd dat de laatste pagina die door de service wordt verwerkt, de inhoud van de blob bepaalt. Om de integriteit van de inhoud van de blob te waarborgen, moet de client schrijfbewerkingen naar overlappende pagina's afhandelen met behulp van een of meer van de volgende methoden:

U kunt de waarde van de Last-Modified antwoordheader controleren voor elke geslaagde aanroep naar Put Page From URL. De volgorde van de antwoorden die door de Blob-service worden geretourneerd, komt niet noodzakelijkerwijs overeen met de volgorde waarin ze door de service zijn uitgevoerd. Maar de waarde van Last-Modified geeft altijd de volgorde aan waarin de service de aanvragen heeft verwerkt.
U kunt updates voorwaardelijk uitvoeren op basis van de ETag van de blob of de laatste wijzigingstijd met behulp van optimistische gelijktijdigheid. Deze aanpak werkt goed als het aantal gelijktijdige schrijfbewerkingen relatief laag is. Gebruik hiervoor de headers If-Matchvoor voorwaardelijke aanvragen , If-None-MatchIf-Modified-Since, en If-Unmodified-Since .
U kunt Lease-blob aanroepen om de blob gedurende een periode van één minuut te vergrendelen tegen andere schrijfbewerkingen, of langer als de lease wordt verlengd.
U kunt het volgnummer van de blob gebruiken om ervoor te zorgen dat het opnieuw proberen van een aanvraag waarvoor geen antwoord is ontvangen, niet leidt tot gelijktijdige updates. Deze benadering is mogelijk het beste voor clients die een hoge doorvoer nodig hebben voor pagina-schrijfbewerkingen. Dit wordt in de volgende sectie in detail beschreven.

Het reeksnummer van de pagina-blob gebruiken om aanvragen opnieuw te proberen

Wanneer een time-out optreedt voor een aanroep Put Page From URL of geen antwoord retourneert, is er geen manier om zeker te weten of de aanvraag is geslaagd. U moet de aanvraag daarom opnieuw proberen, maar vanwege de gedistribueerde aard van de Azure-opslagservices is het mogelijk dat de oorspronkelijke aanvraag wordt verwerkt nadat de aanvraag opnieuw is geprobeerd. De vertraagde oorspronkelijke aanvraag kan andere updates overschrijven en een onverwacht resultaat opleveren. In de volgende volgorde ziet u hoe dit kan gebeuren:

Er Put Page From URL treedt een time-out op bij een aanvraag om de waarde 'X' naar pagina 0 te schrijven of er wordt geen antwoord geretourneerd.
Een nieuwe poging om de waarde 'X' naar pagina 0 te schrijven, slaagt.
Een aanvraag voor het schrijven van de waarde 'Y' naar pagina 0 slaagt.
De oorspronkelijke aanvraag slaagt en de waarde 'X' wordt naar pagina 0 geschreven.
Als u pagina 0 leest, wordt de waarde 'X' geretourneerd, toen de client op dit moment de waarde 'Y' verwachtte.

Dit soort conflict kan optreden wanneer de oorspronkelijke aanvraag geen statuscode tussen 100-499 of 503 (server bezet) retourneert. Als een van deze statuscodes wordt geretourneerd, kunt u er zeker van zijn of de aanvraag is geslaagd of mislukt. Maar als de service een statuscode buiten dit bereik retourneert, is er geen manier om de status van de oorspronkelijke aanvraag te achterhalen.

Om dit soort conflicten te voorkomen, kunt u het volgnummer van de pagina-blob gebruiken om ervoor te zorgen dat wanneer u een aanvraag opnieuw probeert, de oorspronkelijke aanvraag vervolgens niet slaagt. Hiervoor moet u het reeksnummer verhogen voordat u de oorspronkelijke aanvraag opnieuw probeert uit te voeren. U kunt vervolgens de headers voor voorwaardelijke reeksnummers gebruiken om ervoor te zorgen dat de aanvraag mislukt als het volgnummer niet overeenkomt met het verwachte volgnummer. De volgende volgorde illustreert deze benadering:

De client maakt een pagina-blob met Put Blob en stelt het volgnummer in op 0.
Een Put Page From URL aanvraag voor het schrijven van de waarde 'X' naar pagina 0 met de if-sequence-number-lt koptekst ingesteld op 1 een time-out of retourneert geen antwoord.
De client roept Blob-eigenschappen instellen aan om het reeksnummer bij te werken naar 1.
Een opnieuw geprobeerd aanvraag om de waarde 'X' te schrijven naar pagina 0 met if-sequence-number-lt ingesteld op 2 geslaagd.
Een aanvraag voor het schrijven van de waarde 'Y' naar pagina 0 met if-sequence-number-lt ingesteld op 2 slaagt.
De oorspronkelijke aanvraag wordt uiteindelijk verwerkt, maar mislukt omdat hiermee de voorwaarde wordt opgegeven dat het volgnummer kleiner moet zijn dan 1 (de if-sequence-num-lt header is ingesteld op 1). De fout is SequenceNumberConditionNotMet (HTTP-statuscode 412 – Voorwaarde mislukt).
Als u pagina 0 leest, wordt de verwachte waarde van 'Y' geretourneerd.

Zie ook

Aanvragen voor Azure Storage autoriseren
Status en foutcodes
Time-outs instellen voor blobservicebewerkingen

Delen via