Placera sida

Operationen Put Page skriver ett sidintervall till en sidblob.

Begäran

Du kan skapa Put Page begäran enligt följande. Vi rekommenderar att du använder HTTPS. Byt ut myaccount mot namnet på ditt lagringskonto:

PUT-metodens begäran URI	HTTP-version
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page`	HTTP/1.1

Emulerad lagringstjänstbegäran

När du gör en förfrågan mot den emulerade lagringstjänsten, ange emulatorns värdnamn och Blob-serviceporten som 127.0.0.1:10000, följt av namnet på det emulerade lagringskontot:

PUT-metodens begäran URI	HTTP-version
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page`	HTTP/1.1

Mer information finns i Använda Azurite-emulatorn för lokal Azure Storage-utveckling.

URI parametrar

Du kan ange följande ytterligare parametrar på begäran av URI:n:

Parameter	Description
`timeout`	Valfritt. Parametern `timeout` uttrycks i sekunder. För mer information, se Sätt time-outs för Blob-tjänstoperationer.

Förfrågningsrubriker

De obligatoriska och valfria begäranderubrikerna beskrivs i följande tabell:

Förfrågningshuvudrad	Description
`Authorization`	Obligatoriskt. Anger auktoriseringsschema, kontonamn och signatur. Mer information finns i Auktorisera begäranden till Azure Storage.
`Date` eller `x-ms-date`	Obligatoriskt. Anger UTC (Coordinated Universal Time) för begäran. Mer information finns i Auktorisera begäranden till Azure Storage.
`x-ms-version`	Krävs för alla auktoriserade begäranden. Anger vilken version av åtgärden som ska användas för den här begäran. Mer information finns i Versionshantering för Azure Storage-tjänsterna.
`Range`	Antingen `Range` eller `x-ms-range` krävs. Specificerar byteintervallet som ska skrivas som en sida. Både början och slutet av intervallet måste anges. Denna header definieras av HTTP/1.1-protokollspecifikationen. För en siduppdateringsoperation kan sidomfånget vara upp till 4 MiB. För en sidrensningsoperation kan sidintervallet vara lika stort som värdet på blobbens fulla storlek. Eftersom sidor måste justeras med 512-bytes gränser måste startoffset ha en modulus på 512 och slutoffset på 512 – 1. Exempel på giltiga byteintervall är 0-511, 512-1023 och så vidare. Blob Storage accepterar endast ett byteintervall för `Range` headern, och byteintervallet måste anges i följande format: `bytes=startByte-endByte`. Om både och `Rangex-ms-range` är specificerade använder tjänsten värdet av `x-ms-range`. För mer information, se Specificera intervallhuvudet för Blob-tjänstoperationer.
`x-ms-range`	Antingen `Range` eller `x-ms-range` krävs. Specificerar byteintervallet som ska skrivas som en sida. Både början och slutet av intervallet måste anges. Denna header definieras av HTTP/1.1-protokollspecifikationen. För en siduppdateringsoperation kan sidomfånget vara så stort som 4 MiB. För en sidrensningsåtgärd kan sidintervallet vara upp till värdet för blobens fulla storlek. Eftersom sidor måste justeras med 512-byte gränser måste startoffset ha en modul på 512 och slutoffset en modul på 512–1. Exempel på giltiga byteintervall är 0-511, 512-1023, etc. Blob Storage accepterar endast ett byteintervall för `x-ms-range` headern, och byteintervallet måste anges i följande format: `bytes=startByte-endByte`. Om både och `Rangex-ms-range` är specificerade använder tjänsten värdet av `x-ms-range`. Se Ange intervallhuvudet för Blob-tjänstoperationer för mer information.
`Content-Length`	Obligatoriskt. Specificerar antalet bytes som skickas i begäran. När huvudet `x-ms-page-write` sätts till `clear`, måste värdet på detta huvud sättas till `0`.
`Content-MD5`	Valfritt. En MD5-hash av sidans innehåll. Denna hash används för att verifiera sidans integritet under transport. När denna header anges jämför lagringstjänsten hashen av innehållet som har anlänt med detta headervärde. <br / >Notera: Denna MD5-hash lagras inte med blobben. Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran).
`x-ms-content-crc64`	Valfritt. En CRC64-hash av sidans innehåll. Denna hash används för att verifiera sidans integritet under transport. När denna header anges jämför lagringstjänsten hashen av innehållet som har anlänt med detta headervärde. Obs: Denna CRC64-hash lagras inte med blobben. Om de två hashvärdena inte matchar misslyckas åtgärden med felkoden 400 (felaktig begäran). Om både and-headers `x-ms-content-crc64` finns med misslyckas `Content-MD5` förfrågan med 400 (Bad Request). Denna header stöds i version 2019-02-02 och senare.
`x-ms-page-write: {update ¦ clear}`	Obligatoriskt. Du kan ange ett av följande alternativ: - `Update`: Skriver de bytes som anges av begärandets kropp till det angivna intervallet. Och `RangeContent-Length` headers måste matcha för att kunna utföra uppdateringen. - `Clear`: Rensar det angivna området och frigör det utrymme som används för lagring för det området. För att rensa ett intervall, ställ `Content-Length` headern till `0`, och ställ headern `Range` till ett värde som anger intervallet som ska rensas, upp till maximal blobstorlek.
`x-ms-encryption-scope`	Valfritt. Anger krypteringsomfånget som ska användas för att kryptera innehållet i begäran. Denna header stöds i version 2019-02-02 och senare.
`x-ms-lease-id:<ID>`	Krävs om blobben har ett aktivt lån. Om du vill utföra den här åtgärden på en blob med ett aktivt lån anger du ett giltigt låne-ID för det här huvudet.
`x-ms-if-sequence-number-le: <num>`	Valfritt. Om blobbens sekvensnummer är mindre än eller lika med det angivna värdet, fortsätter förfrågan. Annars misslyckas det med felet SequenceNumberConditionNotMet (HTTP-statuskod 412 – Precondition Failed).
`x-ms-if-sequence-number-lt: <num>`	Valfritt. Om blobbens sekvensnummer är mindre än det angivna värdet fortsätter förfrågan. Annars misslyckas det med felet SequenceNumberConditionNotMet (HTTP-statuskod 412 – Precondition Failed).
`x-ms-if-sequence-number-eq: <num>`	Valfritt. Om blobbens sekvensnummer är lika med det angivna värdet, fortsätter förfrågan. Annars misslyckas det med felet SequenceNumberConditionNotMet (HTTP-statuskod 412 – Precondition Failed).
`If-Modified-Since`	Valfritt. Ett `DateTime` värde. Ange denna villkorliga header för att skriva sidan endast om blobben har ändrats sedan angivet datum/tid. Om blobben inte har modifierats returnerar Blob Storage statuskod 412 (Precondition Failed).
`If-Unmodified-Since`	Valfritt. Ett `DateTime` värde. Ange denna villkorliga header för att skriva sidan endast om blobben inte har ändrats sedan angivet datum/tid. Om blobben har ändrats returnerar Blob Storage statuskod 412 (Precondition Failed).
`If-Match`	Valfritt. Ett ETag-värde. Ange ett ETag-värde för denna villkorliga header för att skriva sidan endast om blobbens ETag-värde matchar det angivna värdet. Om värdena inte stämmer returnerar Blob Storage statuskod 412 (Precondition Failed).
`If-None-Match`	Valfritt. Ett ETag-värde. Ange ett ETag-värde för denna villkorliga header för att skriva sidan endast om blobens ETag-värde inte matchar det angivna värdet. Om värdena är identiska returnerar Blob Storage statuskod 412 (Precondition Failed).
`x-ms-client-request-id`	Valfritt. Ger ett klientgenererat, täckande värde med en teckengräns på 1 kibibyte (KiB) som registreras i loggarna när loggning har konfigurerats. Vi rekommenderar starkt att du använder det här huvudet för att korrelera aktiviteter på klientsidan med begäranden som servern tar emot. Mer information finns i Övervaka Azure Blob Storage.

Denna operation stödjer också användningen av villkorliga headers för att utföra operationen endast om ett specificerat villkor är uppfyllt. För mer information, se Specificera villkorliga headers för Blob-tjänsteoperationer.

Förfrågningshuvuden (krypteringsnycklar tillhandahållna av kunden)

Från och med version 2019-02-02 kan du ange följande headers på förfrågan för att kryptera en blob med en kundtillhandahållen nyckel. Kryptering med en nyckel från kunden (och motsvarande uppsättning headers) är valfritt.

Förfrågningshuvudrad	Description
`x-ms-encryption-key`	Obligatoriskt. Den Base64-kodade AES-256-krypteringsnyckeln.
`x-ms-encryption-key-sha256`	Obligatoriskt. Den Base64-kodade SHA256-hashen av krypteringsnyckeln.
`x-ms-encryption-algorithm: AES256`	Obligatoriskt. Specificerar algoritmen som ska användas för kryptering. Värdet på denna header måste vara `AES256`.

Begäranstecknet (strukturerad kropp)

Från och med version 2025-01-05 kan följande rubriker anges i förfrågan för att utnyttja det strukturerade brödtextformatet.

Förfrågningshuvudrad	Description
`Content-Length`	Obligatoriskt. Måste vara längden på den kodade begäran (inte bara längden på sidans innehåll). Om värdet på headern inte matchar den förväntade längden på den kodade förfrågan misslyckas operationen med felkod 400 (Bad Request).
`x-ms-structured-body`	Obligatoriskt. Måste inkluderas om meddelandeformatet är strukturerat. Värdet på denna header innehåller meddelandeschemats version och egenskaper. För närvarande stöds `XSM/1.0; properties=crc64`endast värdet , vilket indikerar att begäran använder crc64-kontrollsummesegment i det kodade meddelandet. Om värdet inte matchar detta misslyckas operationen med felkod 400 (Bad Request). Begäran kommer också att misslyckas om innehållet i förfrågan inte matchar den angivna kontrollsumman för ett givet segment med felkod 400 (Bad Request).
`x-ms-structured-content-length`	Obligatoriskt. Måste inkluderas om meddelandeformatet är strukturerat. Värdet på denna header är längden på sidinnehållet och kommer alltid att vara mindre än `Content-Length` headervärdet på grund av meddelandekodning. Om värdet på headern inte matchar längden på blockinnehållet som anges i förfrågan, misslyckas operationen med felkod 400 (Bad Request).

begäranens innehåll

Förfrågningsdelen innehåller sidans innehåll.

Exempelförfrågan: Uppdateringsbyteintervall

  
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

Exempelförfrågan: Rensa byteintervall

  
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=

Svar

Svaret innehåller en HTTP-statuskod och en uppsättning svarshuvuden.

Statuskod

En lyckad åtgärd returnerar statuskoden 201 (skapad).

Mer information om statuskoder finns i Status och felkoder.

Svarsrubriker

Svaret för den här åtgärden innehåller följande rubriker. Svaret kan också innehålla ytterligare HTTP-standardhuvuden. Alla standardhuvuden överensstämmer med HTTP/1.1-protokollspecifikationen.

Syntax	Description
`ETag`	ETag för blobben. Om begäran-versionen är 2011-08-18 och senare, är ETag-värdet instängt inom citationstecken. ETag kan användas för att utföra en villkorlig `Put Page` operation genom att ange dess värde för `If-Match` eller `If-None-Match` begäran-huvudet.
`Last-Modified`	Datum och tid när blobben senast modifierades. Datumformatet följer RFC 1123. För mer information, se Representera datum/tid-värden i rubriker. Alla skrivoperationer på blobben, inklusive uppdateringar av blobbens metadata eller egenskaper, ändrar blobens senaste modifierade tid.
`Content-MD5`	Det här huvudet returneras så att klienten kan söka efter meddelandets innehållsintegritet. Värdet på denna header beräknas av Blob Storage. Det är inte nödvändigtvis samma som värdet som anges i förfrågningshuvuden. För version 2019-02-02 och senare returneras denna header endast när förfrågan har denna header.
`x-ms-content-crc64`	För version 2019-02-02 eller senare returneras denna header så att klienten kan kontrollera meddelandets innehållsintegritet. Värdet på denna header beräknas av Blob Storage. Det är inte nödvändigtvis samma som värdet som anges i förfrågningshuvuden. Denna header returneras när `Content-MD5` headern inte finns i begäran.
`x-ms-blob-sequence-number`	Det aktuella sekvensnumret för sidbloben.
`x-ms-request-id`	Identifierar unikt den begäran som gjordes, och kan användas för att felsöka förfrågan. Mer information finns i Felsöka API-åtgärder.
`x-ms-version`	Indikerar vilken Blob-tjänstversion som användes för att köra förfrågan. Det här huvudet returneras för begäranden som gjordes mot version 2009-09-19 och senare.
`Date`	Ett UTC-datum/tid-värde som genereras av tjänsten, vilket anger den tid då svaret initierades.
`x-ms-request-server-encrypted: true/false`	Version 2015-12-11 och senare. Värdet på denna header sätts till `true` om innehållet i förfrågan framgångsrikt krypteras med den specificerade algoritmen. Annars sätts värdet till `false`.
`x-ms-encryption-key-sha256`	Version 2019-02-02 och senare. Returnerades om förfrågan använde en nyckel som kunden tillhandahållit för kryptering, så att klienten kan säkerställa att innehållet i förfrågan lyckas krypteras genom att använda den tillhandahållna nyckeln.
`x-ms-encryption-scope`	Version 2019-02-02 och senare. Returnerades om förfrågan använde ett krypteringsscope, så att klienten kan säkerställa att innehållet i begäran är framgångsrikt krypterat genom att använda krypteringsscope.
`x-ms-client-request-id`	Kan användas för att felsöka begäranden och motsvarande svar. Värdet för det här huvudet är lika med värdet för `x-ms-client-request-id`-huvudet om det finns i begäran och värdet inte innehåller fler än 1 024 synliga ASCII-tecken. Om den `x-ms-client-request-id` rubriken inte finns i begäran visas den inte i svaret.
`x-ms-structured-body`	Returnerades om begäran behandlades som en strukturerad kroppsförfrågan. Värdet på denna header är lika med värdet som skickas i förfrågan, vilket för närvarande måste vara `XSM/1.0; properties=crc64`.

Svarsdel

Ingen.

Exempelsvar

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

Auktorisering krävs när du anropar en dataåtkomståtgärd i Azure Storage. Du kan auktorisera åtgärden Put Page enligt beskrivningen nedan.

Viktigt!

Microsoft rekommenderar att du använder Microsoft Entra-ID med hanterade identiteter för att auktorisera begäranden till Azure Storage. Microsoft Entra-ID ger överlägsen säkerhet och användarvänlighet jämfört med auktorisering av delad nyckel.

Azure Storage stöder användning av Microsoft Entra-ID för att auktorisera begäranden till blobdata. Med Microsoft Entra-ID kan du använda rollbaserad åtkomstkontroll i Azure (Azure RBAC) för att bevilja behörigheter till ett säkerhetsobjekt. Säkerhetsobjektet kan vara en användare, grupp, huvudnamn för programtjänsten eller en hanterad Azure-identitet. Säkerhetsprincipen autentiseras av Microsoft Entra ID för att returnera en OAuth 2.0-token. Token kan sedan användas för att auktorisera en begäran mot Blob-tjänsten.

Mer information om auktorisering med Microsoft Entra-ID finns i Auktorisera åtkomst till blobar med hjälp av Microsoft Entra-ID.

Permissions

Nedan visas den RBAC-åtgärd som krävs för att en Microsoft Entra-användare, grupp, hanterad identitet eller tjänstens huvudnamn ska anropa den Put Page åtgärden och den minst privilegierade inbyggda Azure RBAC-rollen som innehåller den här åtgärden:

Azure RBAC action:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Minst privilegierad inbyggd roll:Storage Blob Data-deltagare

Mer information om hur du tilldelar roller med hjälp av Azure RBAC finns i Tilldela en Azure-roll för åtkomst till blobdata.

En signatur för delad åtkomst (SAS) ger säker delegerad åtkomst till resurser i ett lagringskonto. Med en SAS har du detaljerad kontroll över hur en klient kan komma åt data. Du kan ange vilken resurs klienten kan komma åt, vilka behörigheter de har till dessa resurser och hur länge SAS är giltigt.

Åtgärden Put Page stöder tre typer av signaturer för delad åtkomst: sas-för användardelegering, -tjänsten SASoch kontot SAS.

Som bästa säkerhet rekommenderar vi att du använder Microsoft Entra-autentiseringsuppgifter i stället för lagringskontonyckeln, vilket är enklare att kompromettera. Om din programdesign kräver signaturer för delad åtkomst använder du Microsoft Entra-autentiseringsuppgifter för att skapa en SAS för användardelegering när det är möjligt.

När åtkomst till delad nyckel inte tillåts för lagringskontot tillåts inte en SAS-token för tjänsten eller en SAS-kontotoken för en begäran till Blob Storage. Mer information finns i Förstå hur nekande av delad nyckel påverkar SAS-token.

SAS för användardelegering

En SAS för användardelegering skyddas med Microsoft Entra-autentiseringsuppgifter och även av de behörigheter som angetts för SAS.

Att anropa Put Page operationen med en SAS-token som delegerats till en container eller blobresurs kräver Write (w) -behörigheten som en del av användardelegeringstokens SAS-token.

Mer information om SAS för användardelegering finns i Skapa en SAS-för användardelegering.

SAS-tjänst

En tjänst-SAS skyddas med lagringskontonyckeln. En tjänst-SAS delegerar åtkomst till en resurs i en enda Azure Storage-tjänst, till exempel bloblagring.

Att anropa operationen Put Page med en SAS-token som delegerats till en container eller blobresurs kräver Write (w)- behörigheten som en del av tjänstens SAS-token.

Mer information om TJÄNSTEN SAS finns i Skapa en tjänst SAS.

SAS-autentisering för konton

Ett SAS-konto skyddas med lagringskontonyckeln. Ett konto SAS delegerar åtkomst till resurser i en eller flera av lagringstjänsterna. Alla åtgärder som är tillgängliga via en tjänst eller sas för användardelegering är också tillgängliga via ett konto-SAS.

Följande tabell anger den signerade resurstypen och de signerade behörigheter som ska anges när åtkomst delegeras:

Verksamhet	Signerad tjänst	Signerad resurstyp	Signerad behörighet
Placera sida	Blobben (b)	Objekt (o)	Skriv (w)

Mer information om sas-kontot finns i Skapa ett KONTO SAS-.

Anmärkningar

Operationen Put Page skriver ett sidintervall till en sidblob. Denna operation kan endast anropas på en befintlig sidblob. Den kan inte anropas för att skapa en ny sidblob, och den kan inte heller anropas på en blockblob. Anrop Put Page med ett blobnamn som för närvarande inte finns returnerar HTTP-statuskod 404 (Ej hittad).

För att skapa en ny sidblob, anropa Put Blob och ange vilken typ av blob som ska skapas som sidblob. En sidklump kan vara upp till 8 TiB stor.

Om blobben har en aktiv lease måste klienten ange ett giltigt lease-ID på förfrågan för att skriva en sida.

Siduppdateringsoperationer

Anrop Put Page med Update alternativet utför en in-place-skrivning på den angivna sidblobben. Allt innehåll på den angivna sidan skrivs över med uppdateringen.

Viktigt!

Om servern går ut på tidsgränsen eller din anslutning stängs under en Put Page operation kan sidan ha uppdaterats eller inte. Därför bör du fortsätta försöka uppdatera igen tills du får ett svar som visar att du lyckats.

Varje intervall av sidor som skickas in för Put Page en uppdateringsoperation kan vara upp till 4 MiB i storlek. Start- och slutintervallet på sidan måste justeras med 512-bytes gränser. Om du försöker ladda upp ett sidintervall som är större än 4 MiB, returnerar tjänsten statuskod 413 (Request Entity Too Large).

Sidrensningsoperationer

Att kalla Put Page med Clear alternativet frigör det lagringsutrymme som används av den angivna sidan. Sidor som har rensats spåras inte längre som en del av sidklumpen.

Sidor som har rensats har inte längre någon avgift mot lagringskontot, eftersom deras lagringsresurser har frigivits. Det enda undantaget är om det finns existerande ögonblicksbilder av sidblobben. Sidor i snapshots debiteras om samma sidor inte längre finns som en del av källblobben.

Hantera samtidighetsproblem

Blob Storage hanterar samtidiga skrivningar till överlappande sidor sekventiellt. Det vill säga, den sista sidan som bearbetas av tjänsten bestämmer blobens innehåll. Därför bör klienten, för att säkerställa blobens innehålls integritet, hantera skrivningar till överlappande sidor med en eller flera av följande metoder:

Du kan kontrollera värdet på Last-Modified svarheadern för varje lyckat anrop till Put Page. Ordningen på svaren som returneras från Blob Storage motsvarar inte nödvändigtvis den ordning i vilken tjänsten körde dem. Men värdet på Last-Modified anger alltid i vilken ordning tjänsten behandlade förfrågningarna.
Du kan utföra uppdateringar villkorligt baserat på blobbens ETag eller senaste modifierade tid med optimistisk samtidighet. Denna metod fungerar bra om antalet samtidiga skrivningar är relativt lågt. Använd villkorliga förfrågningshuvuden If-Match, If-None-Match, If-Modified-Since, och If-Unmodified-Since för detta ändamål.
Du kan kalla Lease Blob för att låsa blobben mot andra skrivningar under en minutsperiod, eller längre om leasen förnyas.
Du kan använda blobens sekvensnummer för att säkerställa att om du försöker en begäran där det inte svarats på igen inte resulterar i samtidiga uppdateringar. Denna metod kan vara bäst för kunder som kräver hög genomströmning för sidskrivningar. Detta beskrivs i detalj i följande avsnitt.

Använd sidblobens sekvensnummer för att försöka om förfrågningar

När ett samtal om tidsavslut Put Page eller inte ger svar finns det inget sätt att veta säkert om förfrågan lyckades. Du behöver därför försöka om förfrågan men, på grund av den distribuerade naturen hos Azure-lagringstjänsterna, är det möjligt att den ursprungliga förfrågan behandlas efter att den återprövade förfrågan har lyckats. Den fördröjda ursprungliga förfrågan kan skriva över andra uppdateringar och ge ett oväntat resultat. Följande sekvens illustrerar hur detta kan ske:

En Put Page begäran om att skriva värdet "X" till sida 0 går ut eller ger inget svar.
En omprövad förfrågan om att skriva värdet "X" till sida 0 lyckas.
En begäran om att skriva värdet "Y" till sida 0 lyckas.
Den ursprungliga begäran lyckas och skriver värdet "X" till sida 0.
Att läsa sida 0 ger värdet "X", när klienten vid denna punkt förväntade sig värdet "Y".

Denna typ av konflikt kan uppstå när den ursprungliga förfrågan inte returnerar en statuskod från 100 till 499, eller 503 (Server Busy). Om en av dessa statuskoder returneras kan du vara säker på om begäran har lyckats eller misslyckats. Men om tjänsten returnerar en statuskod utanför detta intervall finns det inget sätt att veta statusen för den ursprungliga förfrågan.

För att undvika denna typ av konflikt kan du använda sidblobbens sekvensnummer för att säkerställa att när du försöker igen en förfrågan, lyckas inte den ursprungliga förfrågan. För att göra det bör du öka sekvensnumret innan du försöker med den ursprungliga förfrågan igen. Du kan sedan använda de villkorliga sekvensnummerhuvuden för att säkerställa att förfrågan misslyckas om dess sekvensnummer inte matchar det förväntade sekvensnumret. Följande sekvens illustrerar detta tillvägagångssätt:

Klienten skapar en sidblob med Put Blob och sätter dess sekvensnummer till 0.
En Put Page begäran om att skriva värdet "X" till sida 0 med if-sequence-number-lt headern satt till 1 tidsförsämrad eller ger inget svar.
Klienten anropar Set Blob Properties för att uppdatera sekvensnumret till 1.
En omprövad förfrågan att skriva värdet "X" till sida 0 med if-sequence-number-lt satt till 2 lyckas.
En begäran om att skriva värdet "Y" till sida 0 med if-sequence-number-lt satt till 2 lyckas.
Den ursprungliga förfrågan bearbetas slutligen, men den misslyckas eftersom den specificerar villkoret att sekvensnumret måste vara mindre än 1 (det vill säga if-sequence-num-lt att headern sätts till 1). Felet är SequenceNumberConditionNotMet (HTTP-statuskod 412 – Precondition Failed).
Att läsa sida 0 ger det förväntade värdet av "Y".

Se även

Auktorisera begäranden till Azure Storage
Status och felkoder
Sätt timeouts för Blob-tjänstoperationer

Last updated on 2026-01-22

Dela via