Put Page

Articolo
05/15/2024

Tramite l'operazione Put Page viene scritto un intervallo di pagine in un Blob di pagine.

Richiesta

È possibile costruire la Put Page richiesta come indicato di seguito. È consigliabile usare HTTPS. Sostituire myaccount con il nome dell'account di archiviazione:

URI della richiesta del metodo PUT	Versione HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=page`	HTTP/1.1

Richiesta di servizio di archiviazione emulata

Quando si effettua una richiesta per il servizio di archiviazione emulato, specificare il nome host dell'emulatore e la porta del servizio BLOB come 127.0.0.1:10000, seguito dal nome dell'account di archiviazione emulato:

URI della richiesta del metodo PUT	Versione HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=page`	HTTP/1.1

Per altre informazioni, vedere Usare l'emulatore Azurite per lo sviluppo locale di Archiviazione di Azure.

Parametri URI

Nell'URI della richiesta puoi specificare i parametri seguenti:

Parametro	Descrizione
`timeout`	Facoltativa. Il parametro `timeout` viene espresso in secondi. Per altre informazioni, vedere Impostare i timeout per le operazioni del servizio BLOB.

Intestazioni della richiesta

Le intestazioni di richiesta obbligatorie e facoltative sono descritte nella tabella seguente:

Intestazione della richiesta	Descrizione
`Authorization`	Obbligatorio. Specifica lo schema di autorizzazione, il nome dell'account e la firma. Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`Date` o `x-ms-date`	Obbligatorio. Specifica la data per la richiesta nel fuso orario UTC (Coordinated Universal Time). Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure.
`x-ms-version`	Obbligatorio per tutte le richieste autorizzate. Specifica la versione dell'operazione da usare per questa richiesta. Per altre informazioni, vedere Controllo delle versioni per i servizi di archiviazione di Azure.
`Range`	`Range` o `x-ms-range` è obbligatorio. Specifica l'intervallo di byte da scrivere come pagina. È necessario specificare l'inizio e la fine dell'intervallo. Questa intestazione è definita dalla specifica del protocollo HTTP/1.1. Per un'operazione di aggiornamento della pagina , l'intervallo di pagine può avere un massimo di 4 MiB. Per un'operazione di cancellazione della pagina , l'intervallo di pagine può essere ottimale come il valore delle dimensioni intere del BLOB. Poiché le pagine devono essere allineate con limiti di 512 byte, l'offset iniziale deve essere un modulo di 512 e l'offset finale deve essere un modulo di 512 -1. Esempi di intervalli di byte validi sono 0-511, 512-1023 e così via. Archiviazione BLOB accetta solo un singolo intervallo di byte per l'intestazione `Range` e l'intervallo di byte deve essere specificato nel formato seguente: `bytes=startByte-endByte`. Se `Range` e `x-ms-range` sono entrambi specificati, il servizio usa il valore di `x-ms-range`. Per altre informazioni, vedere Specificare l'intestazione dell'intervallo per le operazioni del servizio BLOB.
`x-ms-range`	`Range` o `x-ms-range` è obbligatorio. Specifica l'intervallo di byte da scrivere come pagina. È necessario specificare l'inizio e la fine dell'intervallo. Questa intestazione è definita dalla specifica del protocollo HTTP/1.1. Per un'operazione di aggiornamento della pagina, l'intervallo di pagine può essere di dimensioni pari a 4 MiB. Per un'operazione di cancellazione di pagine, le dimensioni dell'intervallo possono estendersi fino al valore delle dimensioni totali del Blob. Poiché le pagine devono essere allineate con limiti di 512 byte, l'offset iniziale deve essere un modulo di 512 e l'offset finale deve essere un modulo di 512 - 1. Esempi di intervalli di byte validi sono 0-511, 512-1023 e così via. Archiviazione BLOB accetta solo un singolo intervallo di byte per l'intestazione `x-ms-range` e l'intervallo di byte deve essere specificato nel formato seguente: `bytes=startByte-endByte`. Se `Range` e `x-ms-range` sono entrambi specificati, il servizio usa il valore di `x-ms-range`. Per altre informazioni, vedere Specificare l'intestazione dell'intervallo per le operazioni del servizio BLOB .
`Content-Length`	Obbligatorio. Specifica il numero di byte trasmessi nel corpo della richiesta. Quando l'intestazione `x-ms-page-write` è impostata su `clear`, il valore di questa intestazione deve essere impostato su `0`.
`Content-MD5`	facoltativo. Hash MD5 del contenuto della pagina. Questo hash viene utilizzato per verificare l'integrità della pagina durante il trasporto. Quando questa intestazione viene specificata, il servizio di archiviazione confronta l'hash del contenuto ricevuto con il valore di questa intestazione. <br/ >Nota: questo hash MD5 non viene archiviato con il BLOB. Se i due hash non corrispondono, l'operazione non riesce con codice di errore 400 (richiesta non valida).
`x-ms-content-crc64`	facoltativo. Hash CRC64 del contenuto della pagina. Questo hash viene utilizzato per verificare l'integrità della pagina durante il trasporto. Quando questa intestazione viene specificata, il servizio di archiviazione confronta l'hash del contenuto ricevuto con il valore di questa intestazione. Nota: questo hash CRC64 non viene archiviato con il BLOB. Se i due hash non corrispondono, l'operazione non riesce con codice di errore 400 (richiesta non valida). Se sono presenti entrambe le `Content-MD5` intestazioni e `x-ms-content-crc64` , la richiesta ha esito negativo con una richiesta 400 (richiesta non valida). Questa intestazione è supportata nella versione 2019-02-02 e successive.
`x-ms-page-write: {update ¦ clear}`	Obbligatorio. È possibile specificare una delle opzioni seguenti: - `Update`: scrive i byte specificati dal corpo della richiesta nell'intervallo specificato. Per eseguire l'aggiornamento, è necessario che le intestazioni `Range` e `Content-Length` corrispondano. - `Clear`: cancella l'intervallo specificato e rilascia lo spazio usato nell'archiviazione per tale intervallo. Per cancellare un intervallo, impostare l'intestazione `Content-Length0`su e impostare l'intestazione `Range` su un valore che indica l'intervallo da cancellare, fino alla dimensione massima del BLOB.
`x-ms-encryption-scope`	facoltativo. Indica l'ambito di crittografia da usare per crittografare il contenuto della richiesta. Questa intestazione è supportata nella versione 2019-02-02 e successive.
`x-ms-lease-id:<ID>`	Obbligatoria se il Blob presenta un lease attivo. Per eseguire questa operazione su un Blob con un lease attivo, specificare l'ID lease valido per questa intestazione.
`x-ms-if-sequence-number-le: <num>`	facoltativo. Se il numero di sequenza del BLOB è minore o uguale al valore specificato, la richiesta procede. In caso contrario, ha esito negativo con l'errore SequenceNumberConditionNotMet (codice di stato HTTP 412 - Precondizione non riuscita).
`x-ms-if-sequence-number-lt: <num>`	facoltativo. Se il numero di sequenza del BLOB è minore del valore specificato, la richiesta procede. In caso contrario, l'errore ha esito negativo con l'errore SequenceNumberConditionNotMet (codice di stato HTTP 412 - Precondizione non riuscita).
`x-ms-if-sequence-number-eq: <num>`	facoltativo. Se il numero di sequenza del BLOB è uguale al valore specificato, la richiesta procede. In caso contrario, l'errore ha esito negativo con l'errore SequenceNumberConditionNotMet (codice di stato HTTP 412 - Precondizione non riuscita).
`If-Modified-Since`	facoltativo. Valore `DateTime`. Specificare questa intestazione condizionale per scrivere la pagina solo se il Blob è stato modificato dopo la data e l'ora specificate. Se il BLOB non è stato modificato, l'archiviazione BLOB restituisce il codice di stato 412 (precondizione non riuscita).
`If-Unmodified-Since`	facoltativo. Valore `DateTime`. Specificare questa intestazione condizionale per scrivere la pagina solo se il BLOB non è stato modificato dopo la data/ora specificata. Se il BLOB è stato modificato, l'archiviazione BLOB restituisce il codice di stato 412 (precondizione non riuscita).
`If-Match`	facoltativo. Valore ETag. Specificare un valore ETag per questa intestazione condizionale per scrivere la pagina solo se il valore ETag del Blob corrisponde al valore specificato. Se i valori non corrispondono, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita).
`If-None-Match`	facoltativo. Valore ETag. Specificare un valore ETag per questa intestazione condizionale per scrivere la pagina solo se il valore ETag del BLOB non corrisponde al valore specificato. Se i valori sono identici, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita).
`x-ms-client-request-id`	facoltativo. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) registrato nei log al momento della configurazione della registrazione. È consigliabile usare questa intestazione per correlare le attività lato client alle richieste ricevute dal server. Per altre informazioni, vedere Monitorare Archiviazione BLOB di Azure.

Questa operazione supporta l'utilizzo delle intestazioni condizionali per eseguire l'operazione solo se viene soddisfatta una determinata condizione. Per altre informazioni, vedere Specificare intestazioni condizionali per le operazioni del servizio BLOB.

Intestazioni di richiesta (chiavi di crittografia fornite dal cliente)

A partire dalla versione 2019-02-02, è possibile specificare le intestazioni seguenti nella richiesta per crittografare un BLOB con una chiave fornita dal cliente. La crittografia con una chiave fornita dal cliente (e il set corrispondente di intestazioni) è facoltativa.

Intestazione della richiesta	Descrizione
`x-ms-encryption-key`	Obbligatorio. Chiave di crittografia AES-256 con codifica Base64.
`x-ms-encryption-key-sha256`	Obbligatorio. Hash SHA256 con codifica Base64 della chiave di crittografia.
`x-ms-encryption-algorithm: AES256`	Obbligatorio. Specifica l'algoritmo da utilizzare per la crittografia. Il valore di questa intestazione deve essere `AES256`.

Testo della richiesta

Il corpo della richiesta contiene il contenuto della pagina.

Richiesta di esempio: Intervallo di byte di aggiornamento

  
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

Richiesta di esempio: Cancella intervallo di byte

  
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=

Risposta

Nella risposta sono inclusi un codice di stato HTTP e un set di intestazioni per la risposta.

Codice stato

Un'operazione completata correttamente restituisce il codice di stato 201 (Creato).

Per altre informazioni sui codici di stato, vedere Codici di stato e di errore.

Intestazioni di risposta

Nella risposta per questa operazione sono incluse le intestazioni riportate di seguito; Nella risposta possono anche essere incluse intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1.

Sintassi	Descrizione
`ETag`	Valore ETag per il Blob. Se la versione della richiesta è 2011-08-18 e versioni successive, il valore ETag viene racchiuso tra virgolette. Il valore ETag può essere utilizzato per eseguire un'operazione `Put Page` condizionale specificando il relativo valore per l'intestazione della richiesta `If-Match` o `If-None-Match`.
`Last-Modified`	Data e ora dell'ultima modifica del BLOB. Il formato data è conforme a RFC 1123. Per altre informazioni, vedere Rappresentare i valori di data/ora nelle intestazioni. Qualsiasi operazione di scrittura sul Blob, inclusi aggiornamenti dei metadati o delle proprietà del Blob, comporta la modifica dell'ora dell'ultima modifica del Blob.
`Content-MD5`	Questa intestazione viene restituita in modo che il client possa verificare l'integrità del contenuto del messaggio. Il valore di questa intestazione viene calcolato dall'archiviazione BLOB. Non è necessariamente uguale al valore specificato nelle intestazioni della richiesta. Per la versione 2019-02-02 e successive, questa intestazione viene restituita solo quando la richiesta ha questa intestazione.
`x-ms-content-crc64`	Per la versione 2019-02-02 o successiva, questa intestazione viene restituita in modo che il client possa verificare l'integrità del contenuto del messaggio. Il valore di questa intestazione viene calcolato dall'archiviazione BLOB. Non è necessariamente uguale al valore specificato nelle intestazioni della richiesta. Questa intestazione viene restituita quando `Content-MD5` l'intestazione non è presente nella richiesta.
`x-ms-blob-sequence-number`	Numero di sequenza corrente per il Blob di pagine.
`x-ms-request-id`	Identifica in modo univoco la richiesta effettuata e può essere usata per risolvere i problemi della richiesta. Per altre informazioni, vedere Risolvere i problemi relativi alle operazioni api.
`x-ms-version`	Indica la versione del servizio BLOB utilizzata per eseguire la richiesta. Questa intestazione viene restituita per le richieste effettuate rispetto alla versione 2009-09-19 e successive.
`Date`	Valore di data/ora UTC generato dal servizio, che indica l'ora di avvio della risposta.
`x-ms-request-server-encrypted: true/false`	Versione 2015-12-11 e successive. Il valore di questa intestazione è impostato su `true` se il contenuto della richiesta viene crittografato correttamente usando l'algoritmo specificato. In caso contrario, il valore è impostato su `false`.
`x-ms-encryption-key-sha256`	Versione 2019-02-02 e successive. Restituito se la richiesta ha usato una chiave fornita dal cliente per la crittografia, in modo che il client possa assicurarsi che il contenuto della richiesta venga crittografato correttamente usando la chiave fornita.
`x-ms-encryption-scope`	Versione 2019-02-02 e successive. Restituito se la richiesta ha usato un ambito di crittografia, in modo che il client possa garantire che il contenuto della richiesta venga crittografato correttamente usando l'ambito di crittografia.
`x-ms-client-request-id`	Può essere usato per risolvere i problemi relativi alle richieste e alle risposte corrispondenti. Il valore di questa intestazione è uguale al valore dell'intestazione `x-ms-client-request-id` se è presente nella richiesta e il valore non contiene più di 1.024 caratteri ASCII visibili. Se l'intestazione `x-ms-client-request-id` non è presente nella richiesta, non sarà presente nella risposta.

Corpo della risposta

Nessuno.

Risposta di esempio

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

Autorizzazione

L'autorizzazione è necessaria quando si chiama un'operazione di accesso ai dati in Archiviazione di Azure. È possibile autorizzare l'operazione Put Page come descritto di seguito.

Importante

Microsoft consiglia di usare Microsoft Entra ID con identità gestite per autorizzare le richieste ad Archiviazione di Azure. Microsoft Entra ID offre maggiore sicurezza e facilità d'uso rispetto all'autorizzazione con chiave condivisa.

Archiviazione di Azure supporta l'uso di Microsoft Entra ID per autorizzare le richieste ai dati BLOB. Con Microsoft Entra ID è possibile usare il controllo degli accessi in base al ruolo di Azure per concedere le autorizzazioni a un'entità di sicurezza. L'entità di sicurezza può essere un utente, un gruppo, un'entità servizio applicazione o un'identità gestita di Azure. L'entità di sicurezza viene autenticata da Microsoft Entra ID per restituire un token OAuth 2.0. Il token può quindi essere usato per autorizzare una richiesta relativa al servizio BLOB.

Per altre informazioni sull'autorizzazione tramite Microsoft Entra ID, vedere Autorizzare l'accesso ai BLOB usando Microsoft Entra ID.

Autorizzazioni

Di seguito è riportata l'azione di controllo degli accessi in base al ruolo necessaria per un Microsoft Entra utente, un gruppo, un gruppo, un'identità gestita o un'entità servizio per chiamare l'operazione Put Page e il ruolo controllo degli accessi in base al ruolo di Azure con privilegi minimi che include questa azione:

Azione controllo degli accessi in base al ruolo di Azure:Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Ruolo predefinito con privilegi minimi:Collaboratore ai dati dei BLOB di archiviazione

Per altre informazioni sull'assegnazione dei ruoli tramite il controllo degli accessi in base al ruolo di Azure, vedere Assegnare un ruolo di Azure per l'accesso ai dati BLOB.

Una firma di accesso condiviso fornisce accesso delegato sicuro alle risorse in un account di archiviazione. Con una firma di accesso condiviso è possibile controllare in modo granulare il modo in cui un client può accedere ai dati. È possibile specificare la risorsa a cui il client può accedere, le autorizzazioni necessarie per tali risorse e il periodo di validità della firma di accesso condiviso.

L'operazione Put Page supporta tre tipi di firme di accesso condiviso: firma di accesso condiviso delega utente, firma di accesso condiviso del servizio e firma di accesso condiviso dell'account.

Come procedura consigliata per la sicurezza, è consigliabile usare le credenziali Microsoft Entra anziché la chiave dell'account di archiviazione, che può essere compromessa più facilmente. Se la progettazione dell'applicazione richiede firme di accesso condiviso, usare Microsoft Entra credenziali per creare una firma di accesso condiviso della delega utente, quando possibile.

Quando l'accesso con chiave condivisa non è consentito per l'account di archiviazione, non sarà consentito un token di firma di accesso condiviso del servizio o un token di firma di accesso condiviso dell'account in una richiesta di archiviazione BLOB. Per altre informazioni, vedere Informazioni su come impedire la chiave condivisa influisce sui token di firma di accesso condiviso.

Firma di accesso condiviso di delega utente

Una firma di accesso condiviso della delega utente è protetta con credenziali Microsoft Entra e anche dalle autorizzazioni specificate per la firma di accesso condiviso.

Per chiamare l'operazione Put Page usando un token di firma di accesso condiviso delegato a un contenitore o a una risorsa BLOB, è necessaria l'autorizzazione Scrittura (w) come parte del token di firma di accesso condiviso della delega utente.

Per altre informazioni sulla firma di accesso condiviso della delega utente, vedere Create una firma di accesso condiviso della delega utente.

Firma di accesso condiviso del servizio

Una firma di accesso condiviso del servizio è protetta con la chiave dell'account di archiviazione. Una firma di accesso condiviso del servizio delega l'accesso a una risorsa in un singolo servizio di archiviazione di Azure, ad esempio l'archiviazione BLOB.

Per altre informazioni sulla firma di accesso condiviso del servizio, vedere Create una firma di accesso condiviso del servizio.

Firma di accesso condiviso dell'account

Una firma di accesso condiviso dell'account è protetta con la chiave dell'account di archiviazione. Una firma di accesso condiviso dell'account delega l'accesso alle risorse in uno o più servizi di archiviazione. Tutte le operazioni disponibili tramite una firma di accesso condiviso del servizio o di delega utente sono disponibili anche tramite una firma di accesso condiviso dell'account.

La tabella seguente indica il tipo di risorsa firmata e le autorizzazioni firmate per specificare quando si delega l'accesso:

Operazione	Servizio firmato	Tipo di risorsa firmato	Autorizzazione firmata
Put Page	BLOB (b)	Oggetto (o)	Scrittura (w)

Per altre informazioni sulla firma di accesso condiviso dell'account, vedere Create una firma di accesso condiviso dell'account.

Commenti

Tramite l'operazione Put Page viene scritto un intervallo di pagine in un Blob di pagine. Questa operazione può essere chiamata solo in un BLOB di pagine esistente. Non può essere chiamato per creare un nuovo BLOB di pagine, né può essere chiamato in un BLOB in blocchi. La chiamata Put Page con un nome BLOB che non esiste attualmente restituisce il codice di stato HTTP 404 (Non trovato).

Per creare un nuovo BLOB di pagine, chiamare Put BLOB e specificare il tipo di BLOB da creare come BLOB di pagine. Un BLOB di pagine può avere dimensioni fino a 8 TiB.

Se il BLOB ha un lease attivo, il client deve specificare un ID lease valido nella richiesta per scrivere una pagina.

Operazioni di aggiornamento delle pagine

Se si chiama Put Page con l'opzione Update, si esegue una scrittura sul posto sul Blob di pagine specificato. Il contenuto della pagina specificata viene sovrascritto con l'aggiornamento.

Importante

Se il server si verifica il timeout o la connessione viene chiusa durante un'operazione Put Page , la pagina potrebbe essere stata aggiornata o meno. Pertanto, è necessario continuare a ripetere l'aggiornamento fino a quando non si riceve una risposta che indica l'esito positivo.

Ogni intervallo di pagine inviate con Put Page per un'operazione di aggiornamento può avere dimensioni fino a 4 MiB. L'inizio e la fine dell'intervallo di pagine devono essere allineati al limite di 512 byte. Se si tenta di caricare un intervallo di pagine di dimensioni superiori a 4 MiB, il servizio restituisce il codice di stato 413 (Entità richiesta troppo grande).

Operazioni di cancellazione pagina

La chiamata Put Page con l'opzione Clear rilascia lo spazio di archiviazione usato dalla pagina specificata. Le pagine che sono state cancellate non vengono più rilevate come parte del Blob di pagine.

Le pagine cancellate non comportano più un addebito per l'account di archiviazione, perché le risorse di archiviazione sono state rilasciate. L'unica eccezione è se sono presenti snapshot del BLOB di pagine. Le pagine negli snapshot comportano un addebito se le stesse pagine non esistono più come parte del BLOB di origine.

Gestire i problemi di concorrenza

Archiviazione BLOB gestisce le scritture simultanee in pagine sovrapposte in sequenza. Ovvero, l'ultima pagina elaborata dal servizio determina il contenuto del BLOB. Pertanto, per garantire l'integrità del contenuto del BLOB, il client deve gestire le scritture in pagine sovrapposte usando uno o più degli approcci seguenti:

È possibile controllare il valore dell'intestazione della risposta Last-Modified per ogni chiamata completata a Put Page. L'ordine delle risposte restituite dall'archiviazione BLOB non corrisponde necessariamente all'ordine in cui sono state eseguite dal servizio. Tuttavia, il valore di Last-Modified indica sempre l'ordine in cui il servizio ha elaborato le richieste.
È possibile eseguire gli aggiornamenti in modo condizionale in base al valore ETag del Blob o all'ora dell'ultima modifica utilizzando la concorrenza ottimistica. Questo approccio è la soluzione appropriata se il numero di scritture simultanee è relativamente basso. Utilizzare le intestazioni di richiesta condizionali If-Match, If-None-Match, If-Modified-Since e If-Unmodified-Since a questo scopo.
È possibile chiamare lease BLOB per bloccare il BLOB su altre scritture per un periodo di un minuto o più se il lease viene rinnovato.
È possibile usare il numero di sequenza del BLOB per assicurarsi che la ripetizione di una richiesta per cui non è stata ricevuta alcuna risposta non comporti aggiornamenti simultanei. Questo approccio può essere ideale per i client che richiedono una velocità effettiva elevata per le scritture di pagine. Questa operazione è descritta in dettaglio nella sezione seguente.

Usare il numero di sequenza del BLOB di pagine per ripetere le richieste

Quando si verifica il timeout di una chiamata a Put Page o non restituisce una risposta, non è possibile sapere se la richiesta ha avuto esito positivo. È quindi necessario ripetere la richiesta, ma, a causa della natura distribuita dei servizi di archiviazione di Azure, è possibile che la richiesta originale venga elaborata dopo che la richiesta ritentata è riuscita. La richiesta originale ritardata può sovrascrivere altri aggiornamenti e restituire un risultato imprevisto. La sequenza seguente illustra come ciò potrebbe verificarsi:

Una Put Page richiesta di scrittura del valore "X" nella pagina 0 raggiunge il timeout o non restituisce una risposta.
Una nuova richiesta per scrivere il valore "X" sulla pagina 0 ha esito positivo.
Una richiesta per scrivere il valore "Y" sulla pagina 0 ha esito positivo.
La richiesta originale ha esito positivo, quindi viene scritto il valore "X" sulla pagina 0.
La lettura della pagina 0 restituisce il valore "X", anche se il client a questo punto si aspettava il valore "Y".

Questo tipo di conflitto può verificarsi quando la richiesta originale non restituisce un codice di stato compreso tra 100 e 499 o 503 (Server occupato). Se viene restituito uno di questi codici di stato, si può sapere con sicurezza se la richiesta ha avuto esito positivo o negativo. Se invece il servizio restituisce un codice di stato non compreso in questo intervallo, non vi è modo di conoscere lo stato della richiesta originale.

Per evitare questo tipo di conflitto, è possibile usare il numero di sequenza del BLOB di pagine per assicurarsi che quando si ritenta una richiesta, la richiesta originale non riesce. A tale scopo, incrementare il numero di sequenza prima di ritentare la richiesta originale. È quindi possibile usare le intestazioni del numero di sequenza condizionale per assicurarsi che la richiesta non riesca se il numero di sequenza non corrisponde al numero di sequenza previsto. Nella sequenza seguente viene illustrato questo approccio:

Il client crea un BLOB di pagine con Put BLOB e imposta il numero di sequenza su 0.
Richiesta Put Page di scrittura del valore "X" nella pagina 0 con l'intestazione if-sequence-number-lt impostata su 1 timeout o non restituisce una risposta.
Il client chiama Set Blob Properties per aggiornare il numero di sequenza a 1.
Richiesta ritentata di scrivere il valore "X" nella pagina 0 con if-sequence-number-lt impostato su 2 riuscito.
Richiesta di scrittura del valore "Y" nella pagina 0 con if-sequence-number-lt impostato su 2 succeeds.
La richiesta originale viene infine elaborata, ma ha esito negativo perché specifica la condizione che il numero di sequenza deve essere minore di 1, ovvero l'intestazione if-sequence-num-lt è impostata su 1. L'errore è SequenceNumberConditionNotMet (codice di stato HTTP 412 – Condizione preliminare non riuscita).
La lettura della pagina 0 restituisce il valore "Y" previsto.

Vedi anche

Autorizzare le richieste ad Archiviazione di Azure
Stato e codici errore
Impostare timeout per le operazioni del servizio BLOB

Condividi tramite