Accodamento blocco

Articolo
02/07/2024

L'operazione Append Block esegue il commit di un nuovo blocco di dati alla fine di un BLOB di accodamento esistente.

L'operazione Append Block è consentita solo se il BLOB è stato creato con x-ms-blob-type impostato su AppendBlob. Append Block è supportato solo nella versione 2015-02-21 o successiva.

Richiesta

È possibile costruire la Append Block richiesta come indicato di seguito. È consigliato il protocollo HTTPS. Sostituire myaccount con il nome del proprio account di archiviazione.

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

Quando si effettua una richiesta nel servizio di archiviazione emulato, specificare il nome host dell'emulatore e la porta Archiviazione BLOB di Azure come 127.0.0.1:10000, seguita 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=appendblock`	HTTP/1.1

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

Parametri URI

Parametro	Descrizione
`timeout`	Facoltativa. Il parametro `timeout` viene espresso in secondi. Per altre informazioni, vedere Impostazione dei timeout per le operazioni di Archiviazione BLOB di Azure.

Intestazioni della richiesta

Nella seguente tabella vengono descritte le intestazioni di richiesta obbligatorie e facoltative.

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.
`Content-Length`	Obbligatorio. Lunghezza del contenuto del blocco in byte. Le dimensioni del blocco devono essere inferiori o uguali a 100 MiB (anteprima) per la versione 2022-11-02 e versioni successive. Vedere la sezione Osservazioni per i limiti nelle versioni precedenti. Se la lunghezza non viene specificata, l'operazione ha esito negativo e restituisce il codice di stato 411 (Lunghezza obbligatoria).
`Content-MD5`	facoltativo. Hash MD5 del contenuto del blocco. Questo hash viene utilizzato per verificare l'integrità del blocco durante il trasporto. Quando questa intestazione viene specificata, il servizio di archiviazione confronta l'hash del contenuto ricevuto con il valore di questa intestazione. Si noti che questo hash MD5 non viene archiviato con il BLOB. Se i due hash non corrispondono, l'operazione avrà esito negativo con il codice di errore 400 (richiesta non valida).
`x-ms-content-crc64`	facoltativo. Hash CRC64 del contenuto del blocco di accodamento. Questo hash viene usato per verificare l'integrità del blocco di accodamento durante il trasporto. Quando questa intestazione viene specificata, il servizio di archiviazione confronta l'hash del contenuto ricevuto con il valore di questa intestazione. Si noti che questo hash CRC64 non viene archiviato con il BLOB. Se i due hash non corrispondono, l'operazione avrà esito negativo con il codice di errore 400 (richiesta non valida). Se sono presenti entrambe `Content-MD5` le `x-ms-content-crc64` intestazioni, la richiesta avrà esito negativo con il codice di errore 400. Questa intestazione è supportata nelle versioni 2019-02-02 o successive.
`x-ms-encryption-scope`	facoltativo. Indica l'ambito di crittografia da usare per crittografare il contenuto della richiesta. Questa intestazione è supportata nelle versioni 2019-02-02 o 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-client-request-id`	facoltativo. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) registrato nei log quando la registrazione è configurata. È consigliabile usare questa intestazione per correlare le attività lato client con le richieste ricevute dal server. Per altre informazioni, vedere Monitorare Archiviazione BLOB di Azure.
`x-ms-blob-condition-maxsize`	Intestazione condizionale facoltativa. Specifica la lunghezza massima in byte consentiti per il BLOB di accodamento. Se l'operazione `Append Block` causa il superamento del limite del BLOB o se la dimensione del BLOB è già maggiore del valore specificato in questa intestazione, la richiesta non riesce con il codice di errore 412 (Precondizione non riuscita).
`x-ms-blob-condition-appendpos`	Intestazione condizionale facoltativa, usata solo per l'operazione `Append Block` . Un numero indica l'offset di byte da confrontare. `Append Block` riesce solo se la posizione di accodamento è uguale a questo numero. In caso contrario, la richiesta non riesce con il codice di errore 412 (Precondizione non riuscita).

Questa operazione supporta l'uso di intestazioni condizionali aggiuntive per garantire che l'API abbia esito positivo solo se viene soddisfatta una condizione specificata. Per altre informazioni, vedere Specifica delle intestazioni condizionali per le operazioni di Archiviazione BLOB di Azure.

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) è facoltativo.

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 usare per la crittografia. Il valore di questa intestazione deve essere `AES256`.

Testo della richiesta

Il corpo della richiesta contiene il contenuto del blocco.

Richiesta di esempio

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=appendblock  HTTP/1.1  
  
Request Headers:  
x-ms-version: 2015-02-21  
x-ms-date: <date>  
x-ms-blob-condition-appendpos: 2097152  
x-ms-blob-condition-maxsize: 4194304  
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 1048  
If-Match: "0x8CB172A360EC34B"

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 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.

Intestazione risposta	Descrizione
`ETag`	Contiene `ETag` un valore tra virgolette. Il client può usare il valore per eseguire operazioni condizionali `PUT` usando l'intestazione della `If-Match` richiesta.
`Last-Modified`	Data e ora dell'ultima modifica del BLOB. Il formato data è conforme a RFC 1123. Per altre informazioni, vedere Rappresentazione dei valori di data e ora nelle intestazioni. Qualsiasi operazione di scrittura nel BLOB (inclusi gli aggiornamenti sui metadati o sulle proprietà del BLOB) modifica l'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 lo stesso valore specificato nelle intestazioni della richiesta. Per le versioni 2019-02-02 o successive, questa intestazione viene restituita solo quando la richiesta ha questa intestazione.
`x-ms-content-crc64`	Per le versioni 2019-02-02 o successive, 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 lo stesso valore specificato nelle intestazioni della richiesta. Questa intestazione viene restituita quando l'intestazione `Content-md5` non è presente nella richiesta.
`x-ms-request-id`	Questa intestazione identifica in modo univoco la richiesta effettuata e può essere usata per la risoluzione dei problemi della richiesta.
`x-ms-version`	Indica la versione di Archiviazione BLOB usata per eseguire la richiesta. Questa intestazione viene restituita per le richieste effettuate nella versione 2009-09-19 e successive.
`Date`	Valore di data/ora UTC che indica l'ora in cui è stata avviata la risposta. Il servizio genera questo valore.
`x-ms-blob-append-offset`	Questa intestazione di risposta viene restituita solo per le operazioni di accodamento. Restituisce l'offset in base al quale è stato eseguito il commit del blocco, in byte.
`x-ms-blob-committed-block-count`	Numero di blocchi di cui è stato eseguito il commit presenti nel BLOB. È possibile usarlo per controllare il numero di accodamenti che è possibile eseguire.
`x-ms-request-server-encrypted: true/false`	Versione 2015-12-11 o successiva. 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 o successiva. Questa intestazione viene restituita se la richiesta ha usato una chiave fornita dal cliente per la crittografia. Il client può quindi assicurarsi che il contenuto della richiesta venga crittografato correttamente usando la chiave fornita.
`x-ms-encryption-scope`	Versione 2019-02-02 o successiva. Questa intestazione viene restituita se la richiesta ha usato un ambito di crittografia. Il client può quindi assicurarsi che il contenuto della richiesta venga crittografato correttamente usando l'ambito di crittografia.
`x-ms-client-request-id`	È possibile usare questa intestazione 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. Il valore è al massimo 1024 caratteri ASCII visibili. Se l'intestazione `x-ms-client-request-id` non è presente nella richiesta, questa intestazione non è presente nella risposta.

Risposta di esempio

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: <date>  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-blob-append-offset: 2097152  
x-ms-blob-committed–block-count: 1000

Autorizzazione

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

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 controllo degli accessi in base al ruolo necessaria per un utente, un gruppo o un'entità servizio di Microsoft Entra per chiamare l'operazione Append Block 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/add/action o 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 Append Block 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 Append Block usando un token di firma di accesso condiviso delegato a un contenitore o a una risorsa BLOB, è necessaria l'autorizzazione Add (a) o Write (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 Creare 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 Creare 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
Blocco di accodamento	BLOB (b)	Oggetto (o)	Aggiungere (a) o scrivere (w)

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

L'operazione Append Block supporta l'autorizzazione con chiave condivisa. L'autorizzazione con le chiavi dell'account non è consigliata per la maggior parte degli scenari, perché è meno sicura.

Microsoft consiglia di non consentire l'autorizzazione di chiave condivisa per l'account di archiviazione quando possibile. Per altre informazioni, vedere Impedire l'autorizzazione con chiave condivisa.

Commenti

Append Block carica un blocco alla fine di un BLOB di accodamento esistente. Il blocco di dati è immediatamente disponibile dopo che la chiamata ha esito positivo nel server. Per ogni BLOB di accodamento sono consentiti al massimo 50.000 accodamenti. Ogni blocco può essere di dimensioni diverse.

La tabella seguente descrive le dimensioni massime consentite per blocchi e BLOB, in base alla versione del servizio:

Versione del servizio	Dimensioni massime del blocco (tramite `Append Block`)	Dimensioni massime dei BLOB
Versione 2022-11-02 e successive	100 MiB (anteprima)	Circa 4,75 TiB (100 MiB × 50.000 blocchi)
Versioni precedenti al 2022-11-02	4 MiB	Circa 195 gibibyte (GiB) (4 MiB × 50.000 blocchi)

Append Block riesce solo se il BLOB esiste già.

I BLOB caricati tramite Append Block non espongono ID bloccati. Non è possibile chiamare Get Block List in un BLOB di accodamento. In questo modo si verifica un errore.

È possibile specificare le intestazioni facoltative e condizionali seguenti nella richiesta:

x-ms-blob-condition-appendpos: è possibile impostare questa intestazione su un offset di byte in corrispondenza del quale il client prevede di aggiungere il blocco. La richiesta ha esito positivo solo se l'offset corrente corrisponde a quello specificato dal client. In caso contrario, la richiesta non riesce con il codice di errore 412 (Precondizione non riuscita).

I client che usano un singolo writer possono usare questa intestazione per determinare se un'operazione Append Block ha avuto esito positivo, nonostante un errore di rete.
x-ms-blob-condition-maxsize: i client possono usare questa intestazione per assicurarsi che le operazioni di accodamento non aumentino le dimensioni del BLOB oltre a una dimensione massima prevista in byte. Se la condizione ha esito negativo, la richiesta non riesce con il codice di errore 412 (Precondizione non riuscita).

Se si tenta di caricare un blocco maggiore delle dimensioni consentite, il servizio restituisce il codice di errore 413 (Entità richiesta troppo grande). Nella risposta vengono restituite informazioni aggiuntive sull'errore, incluse le dimensioni massime del blocco in byte. Se si tenta di caricare più di 50.000 blocchi, il servizio restituisce il codice di errore 409 (Conflitto).

Se il Blob presenta un lease attivo, il client deve specificare un ID lease valido nella richiesta per poter scrivere un blocco sul Blob. Se il client non specifica un ID lease o specifica un ID lease non valido, l'archiviazione BLOB restituisce il codice di errore 412 (Precondizione non riuscita). Se il client specifica un ID lease, ma il BLOB non ha un lease attivo, l'archiviazione BLOB restituisce anche il codice di errore 412.

Se si chiama Append Block un BLOB a blocchi o un BLOB di pagine esistente, il servizio restituisce un errore di conflitto. Se si chiama Append Block su un BLOB non esistente, il servizio restituisce anche un errore.

Evitare accodamenti duplicati o ritardati

In un singolo scenario di writer, il client può evitare accodamenti duplicati o scritture ritardate usando l'intestazione condizionale per controllare l'offset *x-ms-blob-condition-appendpos corrente. Il client può anche evitare duplicati o ritardi controllando in ETag modo condizionale, usando If-Match.

In uno scenario di scrittura multiplo, ogni client può usare intestazioni condizionali, ma potrebbe non essere ottimale per le prestazioni. Per la velocità effettiva di accodamento simultaneo più elevata, le applicazioni devono gestire accodamenti ridondanti e accodamenti ritardati nel livello dell'applicazione. Ad esempio, l'applicazione può aggiungere periodi o numeri di sequenza nei dati aggiunti.

Fatturazione

Le richieste di prezzi possono derivare dai client che usano le API di archiviazione BLOB, direttamente tramite l'API REST dell'archiviazione BLOB o da una libreria client di Archiviazione di Azure. Queste richieste accumulano addebiti per transazione. Il tipo di transazione influisce sul modo in cui viene addebitato l'account. Ad esempio, le transazioni di lettura si accumulano in una categoria di fatturazione diversa rispetto alle transazioni di scrittura. Nella tabella seguente viene illustrata la categoria di fatturazione per Append Block le richieste in base al tipo di account di archiviazione:

Operazione	Tipo di account di archiviazione	Categoria di fatturazione
Accodamento blocco	BLOB di blocchi Premium Utilizzo generico v2 Standard Utilizzo generico standard v1	Operazioni di scrittura

Per informazioni sui prezzi per la categoria di fatturazione specificata, vedere prezzi Archiviazione BLOB di Azure.