Share via

Umieść stronę

  • Artykuł

Operacja Put Page zapisuje zakres stron w stronicowym obiekcie blob.

Żądanie

Żądanie można skonstruować Put Page w następujący sposób. Zalecamy używanie protokołu HTTPS. Zastąp ciąg myaccount nazwą konta magazynu:

IDENTYFIKATOR URI żądania PUT Wersja PROTOKOŁU HTTP
https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page HTTP/1.1

Żądanie usługi magazynu emulowanego

Podczas wysyłania żądania względem emulowanej usługi magazynu określ nazwę hosta emulatora i port usługi Blob Service jako 127.0.0.1:10000, a następnie nazwę emulowanego konta magazynu:

IDENTYFIKATOR URI żądania PUT Wersja PROTOKOŁU HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page HTTP/1.1

Aby uzyskać więcej informacji, zobacz Use the Azurite emulator for local Azure Storage development (Używanie emulatora Azurite do lokalnego programowania w usłudze Azure Storage).

Parametry identyfikatora URI

W identyfikatorze URI żądania można określić następujące dodatkowe parametry:

Parametr Opis
timeout Opcjonalny. Parametr jest wyrażony timeout w sekundach. Aby uzyskać więcej informacji, zobacz Ustawianie limitów czasu dla operacji usługi Blob Service.

Nagłówki żądań

Wymagane i opcjonalne nagłówki żądań opisano w poniższej tabeli:

Nagłówek żądania Opis
Authorization Wymagane. Określa schemat autoryzacji, nazwę konta i podpis. Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
Date lub x-ms-date Wymagane. Określa dla żądania godzinę w formacie uniwersalnego czasu koordynowanego (UTC). Aby uzyskać więcej informacji, zobacz Autoryzowanie żądań do usługi Azure Storage.
x-ms-version Wymagane dla wszystkich autoryzowanych żądań. Określa wersję operacji do użycia dla tego żądania. Aby uzyskać więcej informacji, zobacz Przechowywanie wersji usług Azure Storage.
Range Wymagane Range lub x-ms-range wymagane.

Określa zakres bajtów do zapisania jako strony. Należy określić zarówno początek, jak i koniec zakresu. Ten nagłówek jest definiowany przez specyfikację protokołu HTTP/1.1.

W przypadku operacji aktualizacji strony zakres stron może wynosić do 4 MiB. W przypadku operacji czyszczenia strony zakres stron może być tak duży, jak wartość pełnego rozmiaru obiektu blob.

Ponieważ strony muszą być wyrównane do granic 512 bajtów, przesunięcie początkowe musi być modulem 512, a przesunięcie końcowe musi być modulem 512–1. Przykłady prawidłowych zakresów bajtów to 0-511, 512-1023 itd.

Usługa Blob Storage akceptuje tylko jeden zakres bajtów dla nagłówka Range , a zakres bajtów musi być określony w następującym formacie: bytes=startByte-endByte.

Jeśli zostanie określona wartość i Rangex-ms-range zostanie określona, usługa używa wartości x-ms-range. Aby uzyskać więcej informacji, zobacz Określanie nagłówka zakresu dla operacji usługi Blob Service.
x-ms-range Wymagane Range lub x-ms-range wymagane.

Określa zakres bajtów do zapisania jako strony. Należy określić zarówno początek, jak i koniec zakresu. Ten nagłówek jest definiowany przez specyfikację protokołu HTTP/1.1.

W przypadku operacji aktualizacji strony zakres stron może być tak duży, jak rozmiar 4 MiB. W przypadku operacji czyszczenia strony zakres stron może być maksymalnie pełną wartością pełnego rozmiaru obiektu blob.

Ponieważ strony muszą być wyrównane do granic 512 bajtów, przesunięcie początkowe musi być modulem 512, a przesunięcie końcowe musi być modulem 512–1. Przykłady prawidłowych zakresów bajtów to 0-511, 512-1023 itp.

Usługa Blob Storage akceptuje tylko jeden zakres bajtów dla nagłówka x-ms-range , a zakres bajtów musi być określony w następującym formacie: bytes=startByte-endByte.

Jeśli zostanie określona wartość i Rangex-ms-range zostanie określona, usługa używa wartości x-ms-range. Aby uzyskać więcej informacji, zobacz Określanie nagłówka zakresu dla operacji usługi Blob Service .
Content-Length Wymagane. Określa liczbę bajtów przesyłanych w treści żądania. x-ms-page-write Gdy nagłówek jest ustawiony na clearwartość , wartość tego nagłówka musi być ustawiona na 0wartość .
Content-MD5 Opcjonalny. Skrót MD5 zawartości strony. Ten skrót służy do weryfikowania integralności strony podczas transportu. Po określeniu tego nagłówka usługa magazynu porównuje skrót zawartości, która dotarła do tej wartości nagłówka.
<br/ >Uwaga: ten skrót MD5 nie jest przechowywany w obiekcie blob.

Jeśli dwa skróty nie są zgodne, operacja kończy się niepowodzeniem z kodem błędu 400 (Nieprawidłowe żądanie).
x-ms-content-crc64 Opcjonalny. Skrót CRC64 zawartości strony. Ten skrót służy do weryfikowania integralności strony podczas transportu. Po określeniu tego nagłówka usługa magazynu porównuje skrót zawartości, która dotarła do tej wartości nagłówka.

Uwaga: ten skrót CRC64 nie jest przechowywany w obiekcie blob.

Jeśli dwa skróty nie są zgodne, operacja kończy się niepowodzeniem z kodem błędu 400 (Nieprawidłowe żądanie).

Jeśli istnieją zarówno Content-MD5 nagłówki, jak i x-ms-content-crc64 żądanie kończy się niepowodzeniem z błędem 400 (nieprawidłowe żądanie).

Ten nagłówek jest obsługiwany w wersji 2019-02-02 i nowszej.
x-ms-page-write: {update ¦ clear} Wymagane. Można określić jedną z następujących opcji:

- Update: zapisuje bajty określone przez treść żądania do określonego zakresu. Nagłówki Range i Content-Length muszą być zgodne, aby przeprowadzić aktualizację.
- Clear: czyści określony zakres i zwalnia miejsce używane w magazynie dla tego zakresu. Aby wyczyścić zakres, ustaw Content-Length nagłówek na 0, a następnie ustaw Range nagłówek na wartość wskazującą zakres na wyczyszczenie, maksymalnie maksymalny rozmiar obiektu blob.
x-ms-encryption-scope Opcjonalny. Wskazuje zakres szyfrowania używany do szyfrowania zawartości żądania. Ten nagłówek jest obsługiwany w wersji 2019-02-02 i nowszej.
x-ms-lease-id:<ID> Wymagane, jeśli obiekt blob ma aktywną dzierżawę. Aby wykonać tę operację na obiekcie blob z aktywną dzierżawą, określ prawidłowy identyfikator dzierżawy dla tego nagłówka.
x-ms-if-sequence-number-le: <num> Opcjonalny. Jeśli numer sekwencji obiektu blob jest mniejszy lub równy określonej wartości, żądanie będzie kontynuowane. W przeciwnym razie kończy się niepowodzeniem z powodu błędu SequenceNumberConditionNotMet (kod stanu HTTP 412 — Warunek wstępny nie powiodło się).
x-ms-if-sequence-number-lt: <num> Opcjonalny. Jeśli numer sekwencji obiektu blob jest mniejszy niż określona wartość, żądanie będzie kontynuowane. W przeciwnym razie kończy się niepowodzeniem z powodu błędu SequenceNumberConditionNotMet (kod stanu HTTP 412 — Niepowodzenie warunku wstępnego).
x-ms-if-sequence-number-eq: <num> Opcjonalny. Jeśli numer sekwencji obiektu blob jest równy określonej wartości, żądanie będzie kontynuowane. W przeciwnym razie kończy się niepowodzeniem z powodu błędu SequenceNumberConditionNotMet (kod stanu HTTP 412 — Niepowodzenie warunku wstępnego).
If-Modified-Since Opcjonalny. Wartość DateTime . Określ ten nagłówek warunkowy, aby zapisać stronę tylko wtedy, gdy obiekt blob został zmodyfikowany od określonej daty/godziny. Jeśli obiekt blob nie został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego).
If-Unmodified-Since Opcjonalny. DateTime Wartość. Określ ten nagłówek warunkowy, aby zapisać stronę tylko wtedy, gdy obiekt blob nie został zmodyfikowany od określonej daty/godziny. Jeśli obiekt blob został zmodyfikowany, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego).
If-Match Opcjonalny. Wartość elementu ETag. Określ wartość elementu ETag dla tego nagłówka warunkowego, aby zapisać stronę tylko wtedy, gdy wartość elementu ETag obiektu blob jest zgodna z określoną wartością. Jeśli wartości nie są zgodne, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego).
If-None-Match Opcjonalny. Wartość elementu ETag.

Określ wartość elementu ETag dla tego nagłówka warunkowego, aby zapisać stronę tylko wtedy, gdy wartość elementu ETag obiektu blob jest niezgodna z określoną wartością. Jeśli wartości są identyczne, usługa Blob Storage zwraca kod stanu 412 (Niepowodzenie warunku wstępnego).
x-ms-client-request-id Opcjonalny. Zapewnia nieprzezroczystą wartość wygenerowaną przez klienta z limitem znaków 1-kibibyte (KiB) rejestrowanym w dziennikach podczas konfigurowania rejestrowania. Zdecydowanie zalecamy używanie tego nagłówka do korelowania działań po stronie klienta z żądaniami odbieranymi przez serwer. Aby uzyskać więcej informacji, zobacz Monitorowanie Azure Blob Storage.

Ta operacja obsługuje również używanie nagłówków warunkowych do wykonywania operacji tylko wtedy, gdy zostanie spełniony określony warunek. Aby uzyskać więcej informacji, zobacz Określanie nagłówków warunkowych dla operacji usługi Blob Service.

Nagłówki żądań (klucze szyfrowania dostarczone przez klienta)

Począwszy od wersji 2019-02-02, można określić następujące nagłówki w żądaniu szyfrowania obiektu blob przy użyciu klucza dostarczonego przez klienta. Szyfrowanie przy użyciu klucza dostarczonego przez klienta (i odpowiadającego mu zestawu nagłówków) jest opcjonalne.

Nagłówek żądania Opis
x-ms-encryption-key Wymagane. Klucz szyfrowania AES-256 zakodowany w formacie Base64.
x-ms-encryption-key-sha256 Wymagane. Skrót SHA256 zakodowany w formacie Base64 klucza szyfrowania.
x-ms-encryption-algorithm: AES256 Wymagane. Określa algorytm do użycia na potrzeby szyfrowania. Wartość tego nagłówka musi mieć wartość AES256.

Treść żądania

Treść żądania zawiera zawartość strony.

Przykładowe żądanie: aktualizowanie zakresu bajtów

  
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

Przykładowe żądanie: Wyczyść zakres bajtów

  
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=

Reakcja

Odpowiedź zawiera kod stanu HTTP i zestaw nagłówków odpowiedzi.

Kod stanu

Pomyślna operacja zwraca kod stanu 201 (Utworzony).

Aby uzyskać więcej informacji na temat kodów stanu, zobacz Kody stanu i błędów.

Nagłówki odpowiedzi

Odpowiedź na tę operację zawiera następujące nagłówki. Odpowiedź może również zawierać dodatkowe standardowe nagłówki HTTP. Wszystkie standardowe nagłówki są zgodne ze specyfikacją protokołu HTTP/1.1.

Składnia Opis
ETag Element ETag dla obiektu blob. Jeśli wersja żądania to 2011-08-18 lub nowsza, wartość elementu ETag jest ujęta w znaki cudzysłowu. Element ETag może służyć do wykonywania operacji warunkowej Put Page , określając jego wartość dla nagłówka If-Match żądania lub If-None-Match .
Last-Modified Data i godzina ostatniej modyfikacji obiektu blob. Format daty jest zgodny z dokumentem RFC 1123. Aby uzyskać więcej informacji, zobacz Reprezentacja wartości daty/godziny w nagłówkach.

Każda operacja zapisu obiektu blob, w tym aktualizacje metadanych lub właściwości obiektu blob, zmienia czas ostatniej modyfikacji obiektu blob.
Content-MD5 Ten nagłówek jest zwracany, aby klient mógł sprawdzić integralność zawartości wiadomości. Wartość tego nagłówka jest obliczana przez usługę Blob Storage. Nie musi być taka sama jak wartość określona w nagłówkach żądania. W przypadku wersji 2019-02-02 lub nowszej ten nagłówek jest zwracany tylko wtedy, gdy żądanie ma ten nagłówek.
x-ms-content-crc64 W przypadku wersji 2019-02-02 lub nowszej ten nagłówek jest zwracany, aby klient mógł sprawdzić integralność zawartości wiadomości. Wartość tego nagłówka jest obliczana przez usługę Blob Storage. Nie musi być taka sama jak wartość określona w nagłówkach żądania.

Ten nagłówek jest zwracany, gdy Content-MD5 nagłówek nie jest obecny w żądaniu.
x-ms-blob-sequence-number Bieżący numer sekwencji stronicowego obiektu blob.
x-ms-request-id Unikatowo identyfikuje żądanie, które zostało wykonane, i może służyć do rozwiązywania problemów z żądaniem. Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z operacjami interfejsu API.
x-ms-version Wskazuje wersję usługi Blob Service, która została użyta do wykonania żądania. Ten nagłówek jest zwracany w przypadku żądań, które zostały wykonane w wersji 2009-09-19 lub nowszej.
Date Wartość daty/godziny UTC wygenerowana przez usługę, która wskazuje godzinę zainicjowania odpowiedzi.
x-ms-request-server-encrypted: true/false Wersja 2015-12-11 lub nowsza. Wartość tego nagłówka jest ustawiana na true wartość , jeśli zawartość żądania zostanie pomyślnie zaszyfrowana przy użyciu określonego algorytmu. W przeciwnym razie wartość jest ustawiona na false.
x-ms-encryption-key-sha256 Wersja 2019-02-02 lub nowsza. Zwrócony, jeśli żądanie użyło klucza dostarczonego przez klienta do szyfrowania, aby klient mógł upewnić się, że zawartość żądania została pomyślnie zaszyfrowana przy użyciu podanego klucza.
x-ms-encryption-scope Wersja 2019-02-02 lub nowsza. Zwrócone, jeśli żądanie używa zakresu szyfrowania, aby klient mógł upewnić się, że zawartość żądania została pomyślnie zaszyfrowana przy użyciu zakresu szyfrowania.
x-ms-client-request-id Może służyć do rozwiązywania problemów z żądaniami i odpowiadającymi odpowiedziami. Wartość tego nagłówka jest równa wartości x-ms-client-request-id nagłówka, jeśli jest obecna w żądaniu, a wartość zawiera nie więcej niż 1024 widoczne znaki ASCII. x-ms-client-request-id Jeśli nagłówek nie znajduje się w żądaniu, nie będzie on obecny w odpowiedzi.

Treść odpowiedzi

Brak.

Przykładowa odpowiedź

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

Autoryzacja

Autoryzacja jest wymagana podczas wywoływania dowolnej operacji dostępu do danych w usłudze Azure Storage. Możesz autoryzować operację Put Page zgodnie z poniższym opisem.

Ważne

Firma Microsoft zaleca używanie Tożsamość Microsoft Entra z tożsamościami zarządzanymi w celu autoryzowania żądań do usługi Azure Storage. Tożsamość Microsoft Entra zapewnia doskonałe zabezpieczenia i łatwość użycia w porównaniu z autoryzacją klucza wspólnego.

Usługa Azure Storage obsługuje autoryzację żądań do danych obiektów blob przy użyciu Tożsamość Microsoft Entra. Dzięki Tożsamość Microsoft Entra możesz użyć kontroli dostępu opartej na rolach (RBAC) platformy Azure, aby udzielić uprawnień podmiotowi zabezpieczeń. Podmiot zabezpieczeń może być użytkownikiem, grupą, jednostką usługi aplikacji lub tożsamością zarządzaną platformy Azure. Podmiot zabezpieczeń jest uwierzytelniany przez Tożsamość Microsoft Entra w celu zwrócenia tokenu OAuth 2.0. Token może następnie służyć do autoryzowania żądania względem usługi Blob Service.

Aby dowiedzieć się więcej na temat autoryzacji przy użyciu Tożsamość Microsoft Entra, zobacz Autoryzowanie dostępu do obiektów blob przy użyciu Tożsamość Microsoft Entra.

Uprawnienia

Poniżej przedstawiono akcję RBAC niezbędną dla użytkownika Microsoft Entra, grupy, tożsamości zarządzanej lub jednostki usługi w celu wywołania Put Page operacji oraz najmniej uprzywilejowanej wbudowanej roli RBAC platformy Azure, która obejmuje tę akcję:

Aby dowiedzieć się więcej na temat przypisywania ról przy użyciu kontroli dostępu opartej na rolach platformy Azure, zobacz Przypisywanie roli platformy Azure w celu uzyskania dostępu do danych obiektów blob.

Uwagi

Operacja Put Page zapisuje zakres stron w stronicowym obiekcie blob. Tę operację można wywołać tylko w istniejącym stronicowym obiekcie blob. Nie można jej wywołać w celu utworzenia nowego stronicowego obiektu blob ani wywołać go w blokowym obiekcie blob. Wywołanie Put Page przy użyciu nazwy obiektu blob, który obecnie nie istnieje, zwraca kod stanu HTTP 404 (Nie znaleziono).

Aby utworzyć nowy stronicowy obiekt blob, wywołaj metodę Put Blob i określ typ obiektu blob do utworzenia jako stronicowy obiekt blob. Stronicowy obiekt blob może mieć rozmiar do 8 TiB.

Jeśli obiekt blob ma aktywną dzierżawę, klient musi określić prawidłowy identyfikator dzierżawy na żądaniu, aby zapisać stronę.

Operacje aktualizacji strony

Wywołanie Put Page za Update pomocą opcji wykonuje zapis w miejscu na określonym stronicowym obiekcie blob. Każda zawartość na określonej stronie zostanie zastąpiona aktualizacją.

Ważne

Jeśli przekroczono limit czasu serwera lub połączenie zostało zamknięte podczas Put Page operacji, strona może lub nie została zaktualizowana. W związku z tym należy kontynuować ponawianie próby aktualizacji do momentu otrzymania odpowiedzi wskazującej powodzenie.

Każdy zakres stron przesłanych Put Page za pomocą operacji aktualizacji może mieć rozmiar do 4 miB. Zakres początkowy i końcowy strony musi być wyrównany do granic 512 bajtów. Jeśli spróbujesz przekazać zakres stron o rozmiarze większym niż 4 miB, usługa zwróci kod stanu 413 (Jednostka żądania zbyt duża).

Operacje czyszczenia strony

Wywołanie Put Page za Clear pomocą opcji zwalnia miejsce do magazynowania używane przez określoną stronę. Strony, które zostały wyczyszczone, nie są już śledzone w ramach stronicowego obiektu blob.

Strony, które zostały wyczyszczone, nie są już naliczane opłaty za konto magazynu, ponieważ ich zasoby magazynu zostały wydane. Jedynym wyjątkiem jest to, że istnieją migawki stronicowego obiektu blob. Opłaty za strony w migawkach są naliczane, jeśli te same strony nie istnieją już w ramach źródłowego obiektu blob.

Zarządzanie problemami współbieżności

Usługa Blob Storage obsługuje współbieżne operacje zapisu na nakładających się stronach sekwencyjnie. Oznacza to, że ostatnia strona przetworzona przez usługę określa zawartość obiektu blob. W związku z tym, aby zapewnić integralność zawartości obiektu blob, klient powinien obsługiwać operacje zapisu na nakładających się stronach przy użyciu co najmniej jednego z następujących podejść:

  • Możesz sprawdzić wartość nagłówka odpowiedzi dla każdego pomyślnego Last-Modified wywołania metody Put Page. Kolejność odpowiedzi zwróconych z usługi Blob Storage nie musi odpowiadać kolejności, w jakiej zostały wykonane przez usługę. Jednak wartość Last-Modified zawsze wskazuje kolejność przetwarzania żądań przez usługę.

  • Aktualizacje można wykonywać warunkowo na podstawie elementu ETag obiektu blob lub czasu ostatniej modyfikacji przy użyciu optymistycznej współbieżności. Takie podejście działa dobrze, jeśli liczba współbieżnych zapisów jest stosunkowo niska. Użyj nagłówków żądań warunkowych If-Match, , If-None-MatchIf-Modified-Sincei If-Unmodified-Since w tym celu.

  • Możesz wywołać dzierżawę obiektu blob , aby zablokować obiekt blob względem innych zapisów w ciągu jednej minuty lub dłużej, jeśli dzierżawa zostanie odnowiona.

  • Możesz użyć numeru sekwencji obiektu blob, aby upewnić się, że ponawianie żądania, dla którego nie było odpowiedzi, nie powoduje równoczesnych aktualizacji. Takie podejście może być najlepsze dla klientów, którzy wymagają wysokiej przepływności w przypadku zapisów stron. Opisano to szczegółowo w poniższej sekcji.

Użyj numeru sekwencji stronicowych obiektów blob, aby ponowić próby żądań

Gdy wywołanie przekroczenia Put Page limitu czasu lub nie zwraca odpowiedzi, nie ma możliwości ustalenia, czy żądanie zakończyło się pomyślnie. W związku z tym należy ponowić próbę wykonania żądania, ale ze względu na rozproszony charakter usług Azure Storage możliwe jest, że oryginalne żądanie może zostać przetworzone po pomyślnym wykonaniu żądania. Opóźnione oryginalne żądanie może zastąpić inne aktualizacje i spowodować nieoczekiwany wynik. Poniższa sekwencja ilustruje, jak to może się zdarzyć:

  1. Put Page Żądanie zapisu wartości "X" do strony 0 razy lub nie zwraca odpowiedzi.

  2. Żądanie ponownego zapisania wartości "X" do strony 0 kończy się powodzeniem.

  3. Żądanie zapisu wartości "Y" do strony 0 kończy się powodzeniem.

  4. Oryginalne żądanie powiedzie się, pisząc wartość "X" na stronę 0.

  5. Odczytywanie strony 0 zwraca wartość "X", gdy klient oczekiwał wartości "Y".

Ten rodzaj konfliktu może wystąpić, gdy oryginalne żądanie nie zwraca kodu stanu z zakresu od 100 do 499 lub 503 (Serwer zajęty). Jeśli zostanie zwrócony jeden z tych kodów stanu, możesz mieć pewność, czy żądanie zakończyło się powodzeniem, czy niepowodzeniem. Jeśli jednak usługa zwróci kod stanu poza tym zakresem, nie ma możliwości poznania stanu oryginalnego żądania.

Aby zapobiec temu rodzajowi konfliktu, możesz użyć numeru sekwencji stronicowego obiektu blob, aby upewnić się, że po ponowieniu żądania oryginalne żądanie nie powiedzie się. W tym celu należy zwiększać numer sekwencji przed ponowieniem próby wykonania oryginalnego żądania. Następnie możesz użyć nagłówków numerów sekwencji warunkowej, aby upewnić się, że żądanie zakończy się niepowodzeniem, jeśli jego numer sekwencji nie jest zgodny z oczekiwanym numerem sekwencji. Poniższa sekwencja ilustruje takie podejście:

  1. Klient tworzy stronicowy obiekt blob z obiektem Put Blob i ustawia jego numer sekwencji na 0.

  2. Put Page Żądanie zapisu wartości "X" na stronę 0 z nagłówkiem ustawionym if-sequence-number-lt na 1 limit czasu lub nie zwraca odpowiedzi.

  3. Klient wywołuje wywołanie Set Blob Properties w celu zaktualizowania numeru sekwencji do 1.

  4. Ponowione żądanie zapisu wartości "X" na stronę 0 z ustawionym if-sequence-number-lt na 2 powodzenie.

  5. Żądanie zapisu wartości "Y" na stronę 0 z ustawionym if-sequence-number-lt na 2 powodzenie.

  6. Oryginalne żądanie jest ostatecznie przetwarzane, ale kończy się niepowodzeniem, ponieważ określa warunek, że numer sekwencji musi być mniejszy niż 1 (oznacza to, if-sequence-num-lt że nagłówek jest ustawiony na 1wartość ). Błąd to SequenceNumberConditionNotMet (kod stanu HTTP 412 — Niepowodzenie warunku wstępnego).

  7. Odczytywanie strony 0 zwraca oczekiwaną wartość "Y".

Zobacz też

Autoryzowanie żądań do usługi Azure Storage
Kody stanu i błędów
Ustawianie limitów czasu dla operacji usługi Blob Service