Put Block List

Articolo
03/16/2023

Tramite l'operazione Put Block List viene scritto un Blob specificando l'elenco di ID dei blocchi che lo compongono. Per essere scritto come parte di un BLOB, è necessario che un blocco sia stato scritto correttamente nel server in un'operazione Put Block precedente.

È possibile chiamare Put Block List per aggiornare un BLOB caricando solo i blocchi modificati e quindi eseguendo il commit dei blocchi nuovi ed esistenti. A tale scopo, è possibile specificare se eseguire il commit di un blocco dall'elenco di blocchi di cui è stato eseguito il commit o dall'elenco di blocchi di cui non è stato eseguito il commit oppure di eseguire il commit della versione caricata più di recente del blocco, a seconda dell'elenco a cui appartiene.

Richiesta

È possibile costruire la Put Block List 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=blocklist`	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=blocklist`	HTTP/1.1

L'emulatore di archiviazione supporta solo le dimensioni dei BLOB fino a 2 gibibyte (GiB).

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.
`Content-Length`	Obbligatorio. Lunghezza in byte del contenuto della richiesta. Questa intestazione fa riferimento alla lunghezza del contenuto dell'elenco di blocchi, non del BLOB stesso.
`Content-MD5`	facoltativo. Hash MD5 del contenuto della richiesta. Questo hash viene utilizzato per verificare l'integrità del contenuto della richiesta durante il trasporto. Se i due hash non corrispondono, l'operazione non riesce con codice di errore 400 (richiesta non valida). Questa intestazione è associata al contenuto della richiesta e non al contenuto del BLOB stesso.
`x-ms-content-crc64`	facoltativo. Hash CRC64 del contenuto della richiesta. Questo hash viene utilizzato per verificare l'integrità del contenuto della richiesta durante il trasporto. Se i due hash non corrispondono, l'operazione non riesce con codice di errore 400 (richiesta non valida). Questa intestazione è associata al contenuto della richiesta e non al contenuto del BLOB stesso. Se sono presenti intestazioni Content-MD5 e x-ms-content-crc64, la richiesta ha esito negativo con 400 (richiesta non valida). Questa intestazione è supportata nella versione 2019-02-02 e successive.
`x-ms-blob-cache-control`	facoltativo. Imposta il controllo della cache del Blob. Se questa proprietà viene specificata, viene archiviata con il BLOB e restituita con una richiesta di lettura. Se la proprietà non viene specificata con la richiesta, viene cancellata per il BLOB se la richiesta ha esito positivo.
`x-ms-blob-content-type`	facoltativo. Imposta il tipo di contenuto del Blob. Se viene specificato, questa proprietà viene archiviata con il BLOB e restituita con una richiesta di lettura. Se il tipo di contenuto non è specificato, viene impostato sul tipo predefinito, ovvero `application/octet-stream`.
`x-ms-blob-content-encoding`	facoltativo. Imposta la codifica del contenuto del Blob. Se viene specificato, questa proprietà viene archiviata con il BLOB e restituita con una richiesta di lettura. Se la proprietà non viene specificata con la richiesta, viene cancellata per il BLOB se la richiesta ha esito positivo.
`x-ms-blob-content-language`	facoltativo. Imposta la lingua del contenuto del BLOB. Se viene specificato, questa proprietà viene archiviata con il BLOB e restituita con una richiesta di lettura. Se la proprietà non viene specificata con la richiesta, viene cancellata per il BLOB se la richiesta ha esito positivo.
`x-ms-blob-content-md5`	facoltativo. Hash MD5 del contenuto del Blob. Questo hash non viene convalidato perché gli hash per i singoli blocchi sono stati convalidati al momento del caricamento. L'operazione Get BLOB restituisce il valore di questa intestazione nell'intestazione della risposta Content-MD5. Se questa proprietà non viene specificata con la richiesta, viene cancellata per il BLOB se la richiesta ha esito positivo.
`x-ms-meta-name:value`	facoltativo. Coppie nome-valore definite dall'utente associate al BLOB. A partire dalla versione 2009-09-19, i nomi dei metadati devono rispettare le regole di denominazione per gli identificatori C#.
`x-ms-encryption-scope`	facoltativo. Indica l'ambito di crittografia da usare per crittografare il BLOB. Questo valore deve corrispondere all'ambito di crittografia usato per crittografare tutti i blocchi di cui viene eseguito il commit. Questa intestazione è supportata nella versione 2019-02-02 e successive.
`x-ms-encryption-context`	facoltativo. Il valore predefinito è "Empty". Se il valore è impostato, verranno impostati i metadati del sistema BLOB. Lunghezza massima 1024. Valido solo quando lo spazio dei nomi gerarchico è abilitato per l'account. Questa intestazione è supportata nelle versioni 2021-08-06 e successive.
`x-ms-tags`	facoltativo. Imposta i tag codificati della stringa di query specificati nel BLOB. Per altre informazioni, vedere la sezione Osservazioni . Supportato nella versione 2019-12-12 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-client-request-id`	facoltativo. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) registrato nei log di analisi quando è configurata la registrazione di Analisi archiviazione. È consigliabile usare questa intestazione per correlare le attività lato client alle richieste ricevute dal server.
`x-ms-blob-content-disposition`	facoltativo. Imposta l'intestazione `Content-Disposition` del BLOB. Disponibile per la versione 2013-08-15 e versioni successive. Il `Content-Disposition` campo intestazione fornisce informazioni aggiuntive su come elaborare il payload della risposta e può essere usato per collegare metadati aggiuntivi. Ad esempio, se è impostato su `attachment`, questa intestazione indica che l'agente utente non deve visualizzare la risposta, ma deve invece visualizzare una finestra di dialogo Salva con nome. La risposta dalle operazioni Get BLOB e Get BLOB Properties include l'intestazione di eliminazione del contenuto.
`x-ms-access-tier`	facoltativo. Versione 2018-11-09 e versioni successive. Indica il livello da impostare in un BLOB. Per i BLOB a blocchi, questa intestazione è supportata negli account di archiviazione BLOB o per utilizzo generico v2 solo con la versione 2018-11-09 e versioni successive. I valori validi per i livelli BLOB in blocchi sono `Hot`, `Cool`, `Cold`e `Archive`. Nota: `Cold` il livello è supportato per la versione 2021-12-02 e successiva. Per informazioni dettagliate sul livello BLOB a blocchi , vedere Livelli di archiviazione ad accesso frequente, sporadico e archivio.
`x-ms-immutability-policy-until-date`	Versione 2020-06-12 e versioni successive. Specifica la data di conservazione fino alla data da impostare nel BLOB. Questa è la data fino alla quale il BLOB può essere protetto da essere modificato o eliminato. Segue RFC1123 formato.
`x-ms-immutability-policy-mode`	Versione 2020-06-12 e versioni successive. Specifica la modalità dei criteri di non modificabilità da impostare nel BLOB. I valori validi sono `unlocked` e `locked`. Il `unlocked` valore indica che gli utenti possono modificare i criteri aumentando o riducendo la data di conservazione . Il `locked` valore indica che queste azioni sono vietate.
`x-ms-legal-hold`	Versione 2020-06-12 e versioni successive. Specifica il blocco legale da impostare nel BLOB. I valori validi sono `true` e `false`.
`x-ms-expiry-option`	facoltativo. Versione 2023-08-03 e versioni successive. Specifica l'opzione data di scadenza per la richiesta, vedere ExpiryOption. Questa intestazione è valida per gli account con spazio dei nomi gerarchico abilitato.
`x-ms-expiry-time`	facoltativo. Versione 2023-08-03 e versioni successive. Specifica l'ora in cui il BLOB è impostato per la scadenza. Il formato per la data di scadenza varia in base a `x-ms-expiry-option`. Per altre informazioni, vedere ExpiryOption. Questa intestazione è valida per gli account con spazio dei nomi gerarchico abilitato. L'oggetto `expiryTime` già presente in un BLOB non viene cancellato se la richiesta non contiene un nuovo valore `expiryTime`

Questa operazione supporta anche l'utilizzo delle intestazioni condizionali per eseguire il commit dell'elenco di elementi bloccati solo se viene soddisfatta una determinata condizione. Per altre informazioni, vedere Specificare intestazioni condizionali per le operazioni di archiviazione 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) è 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

Nel corpo della richiesta è possibile specificare l'elenco di blocchi che l'archiviazione BLOB deve controllare per il blocco richiesto. In questo modo, è possibile aggiornare un BLOB esistente inserendo, sostituendo o eliminando singoli blocchi, anziché ricaricare l'intero BLOB. Dopo aver caricato il blocco o i blocchi modificati, è possibile eseguire il commit di una nuova versione del BLOB eseguendo il commit dei nuovi blocchi insieme ai blocchi esistenti che si desidera mantenere.

Per aggiornare un Blob, è possibile specificare che il servizio cerchi un ID blocco nell'elenco dei blocchi di cui è stato eseguito il commit e poi nell'elenco di quelli di cui non è stato eseguito oppure viceversa. Per indicare quale approccio usare, specificare l'ID blocco all'interno dell'elemento XML appropriato all'interno del corpo della richiesta, come indicato di seguito:

Specificare l'ID blocco all'interno dell'elemento per indicare che l'archiviazione Committed BLOB deve cercare solo l'elenco di blocchi commit per il blocco denominato. Se il blocco non viene trovato nell'elenco blocchi di commit, non viene scritto come parte del BLOB e l'archiviazione BLOB restituisce il codice di stato 400 (richiesta non valida).
Specificare l'ID blocco all'interno dell'elemento Uncommitted per indicare che l'archiviazione BLOB deve cercare solo l'elenco di blocchi non commesso per il blocco denominato. Se il blocco non viene trovato nell'elenco di blocchi non commesso, non viene scritto come parte del BLOB e l'archiviazione BLOB restituisce il codice di stato 400 (richiesta non valida).
Specificare l'ID blocco all'interno dell'elemento per indicare che l'archiviazione BLOB deve prima cercare l'elenco Latest di blocchi non generato. Se il blocco viene trovato nell'elenco dei blocchi di cui non è stato eseguito il commit, questa versione del blocco è la più recente e pertanto deve essere scritta nel Blob. Se il blocco non viene trovato nell'elenco non generato, il servizio deve cercare l'elenco di blocchi di commit per il blocco denominato e scrivere tale blocco nel BLOB se viene trovato.

Il corpo della richiesta per questa versione di Put Block List usa il formato XML seguente:

<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Committed>first-base64-encoded-block-id</Committed>  
  <Uncommitted>second-base64-encoded-block-id</Uncommitted>  
  <Latest>third-base64-encoded-block-id</Latest>  
  ...  
</BlockList>

Richiesta di esempio

Per dimostrare Put Block List, si supponga di aver caricato tre blocchi che si desidera eseguire il commit. Nell'esempio seguente viene eseguito il commit di un nuovo Blob indicando l'utilizzo della versione più recente di ogni blocco elencato. Non è necessario sapere se di questi blocchi è già stato eseguito il commit.

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Latest>AAAAAA==</Latest>  
  <Latest>AQAAAA==</Latest>  
  <Latest>AZAAAA==</Latest>  
</BlockList>

Si supponga quindi di voler aggiornare il BLOB. Il nuovo BLOB presenta le modifiche seguenti:

Un nuovo blocco con ID ANAAAA==. Questo blocco deve prima essere caricato con una chiamata a Put Block e viene visualizzato nell'elenco blocchi noncommesso fino a quando la chiamata a Put Block List.
Versione aggiornata del blocco con ID AZAAAA==. Questo blocco deve prima essere caricato con una chiamata a Put Block e viene visualizzato nell'elenco blocchi noncommesso fino a quando la chiamata a Put Block List.
Rimozione del blocco con ID AAAAAA==. Poiché questo blocco non è incluso nella chiamata successiva a Put Block List, il blocco viene effettivamente rimosso dal BLOB.

Nell'esempio seguente viene illustrata la chiamata a Put Block List per aggiornare il Blob:

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=blocklist HTTP/1.1  
  
Request Headers:  
x-ms-date: Wed, 31 Aug 2009 00:17:43 GMT  
x-ms-version: 2011-08-18  
Content-Type: text/plain; charset=UTF-8  
x-ms-expiry-option: RelativeToNow
x-ms-expiry-time: 30000
Authorization: SharedKey myaccount:DJ5QZSVONZ64vAhnN/wxcU+Pt5HQSLAiLITlAU76Lx8=  
Content-Length: 133  
  
Request Body:  
<?xml version="1.0" encoding="utf-8"?>  
<BlockList>  
  <Uncommitted>ANAAAA==</Uncommitted>  
  <Committed>AQAAAA==</Committed>  
  <Uncommitted>AZAAAA==</Uncommitted>  
</BlockList>

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; inoltre, possono essere incluse intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1.

Risposta	Descrizioni
`ETag`	Il tag dell'entità contiene un valore che il client può utilizzare per eseguire operazioni `GET/PUT` condizionali utilizzando l'intestazione della richiesta `If-Match`. Se la versione della richiesta è 2011-08-18 o successiva, il valore ETag è racchiuso tra virgolette.
`Last-Modified`	Data e ora dell'ultima modifica del Blob. Il formato data è conforme a RFC 1123. Per altre informazioni, vedere Rappresentare valori di data/ora nelle intestazioni. Qualsiasi operazione che comporta la modifica del Blob, incluso un aggiornamento dei metadati o delle proprietà del Blob, comporta la modifica anche dell'ora dell'ultima modifica del Blob.
`Content-MD5`	Restituito in modo che il client possa verificare l'integrità del contenuto del messaggio. Questa intestazione fa riferimento al contenuto della richiesta (in questo caso, l'elenco di blocchi e non il contenuto del BLOB stesso). Per la versione 2019-02-02 e successiva, questa intestazione viene restituita solo quando la richiesta ha questa intestazione.
`x-ms-content-crc64`	Per la versione 2019-02-02 e successiva, questa intestazione viene restituita in modo che il client possa verificare l'integrità del contenuto del messaggio. Questa intestazione fa riferimento al contenuto della richiesta (in questo caso, l'elenco di blocchi e non il contenuto del BLOB stesso). Questa intestazione viene restituita quando `Content-md5` l'intestazione non è presente nella richiesta.
`x-ms-request-id`	Identifica in modo univoco la richiesta effettuata ed è possibile usarla per risolvere i problemi della richiesta. Per altre informazioni, vedere Risolvere i problemi relativi alle operazioni api.
`x-ms-version`	Versione dell'archiviazione BLOB usata 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 quando è stata avviata la 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. Questa intestazione viene restituita 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. Questa intestazione viene restituita se la richiesta ha usato un ambito di crittografia, in modo che il client possa assicurarsi che il contenuto della richiesta venga crittografato correttamente usando l'ambito di crittografia.
`x-ms-version-id: <DateTime>`	Versione 2019-12-12 e successive. Restituisce un valore opaco che identifica in modo univoco `DateTime` il BLOB. Il valore di questa intestazione indica la versione del BLOB e può essere usata nelle richieste successive per accedere al BLOB.
`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 è presente nella risposta.

Risposta di esempio

Response Status:  
HTTP/1.1 201 Created  
  
Response Headers:  
Transfer-Encoding: chunked  
x-ms-content-crc64: 77uWZTolTHU  
Date: Sun, 25 Sep 2011 00:17:44 GMT  
ETag: “0x8CB172A360EC34B”  
Last-Modified: Sun, 25 Sep 2011 00:17:43 GMT  
x-ms-version: 2011-08-18  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0  
x-ms-version-id: <DateTime>

Autorizzazione

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

Se una richiesta specifica i tag con l'intestazione della x-ms-tags richiesta, il chiamante deve soddisfare i requisiti di autorizzazione dell'operazione Imposta tag BLOB .

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 Put Block List 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 Block List 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 Block List 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 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
Put Block List	BLOB (b)	Oggetto (o)	Scrittura (w)

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

L'operazione Put Block List 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

Tramite l'operazione Put Block List viene imposto l'ordine in cui i blocchi devono essere combinati per creare un Blob.

Lo stesso ID blocco può essere specificato più di una volta nell'elenco dei blocchi. Se un ID blocco viene specificato più volte, rappresenta l'intervallo di byte in ognuno di questi percorsi nell'elenco di blocchi per il BLOB di cui è stato eseguito il commit finale. Se un ID blocco viene visualizzato più di una volta nell'elenco, tutte le istanze dell'ID blocco devono essere specificate nello stesso elenco di blocchi. In altre parole, tutte le istanze devono essere specificate nell'elemento Committed, nell'elemento Uncommitted o nell'elemento Latest.

Con Put Block Listè possibile modificare un BLOB esistente inserendo, aggiornando o eliminando singoli blocchi senza dover caricare nuovamente l'intero BLOB. È possibile specificare ID blocco sia dall'elenco dei blocchi di cui è stato eseguito il commit sia da quello dei blocchi di cui non è stato eseguito il commit per creare un nuovo Blob o aggiornare il contenuto di un Blob esistente. In questo modo, è possibile aggiornare un BLOB specificando alcuni nuovi blocchi dall'elenco di blocchi di cui non è stato eseguito il commit e il resto dall'elenco dei blocchi di cui è stato eseguito il commit, che fanno già parte del BLOB esistente.

Se un ID blocco viene specificato nell'elemento Latest e lo stesso ID blocco esiste sia nell'elenco dei blocchi di cui è stato eseguito il commit sia in quello dei blocchi di cui non è stato eseguito il commit, Put Block List esegue il commit del blocco dall'elenco dei blocchi di cui non è stato eseguito il commit. Se l'ID blocco esiste nell'elenco dei blocchi di cui è stato eseguito il commit ma non nell'elenco dei blocchi di cui non è stato eseguito il commit, Put Block List esegue il commit del blocco dall'elenco di blocchi di cui è stato eseguito il commit.

Ogni blocco in un BLOB in blocchi può essere di dimensioni diverse. Un BLOB in blocchi può includere un massimo di 50.000 blocchi di cui è stato eseguito il commit. Il numero massimo di blocchi di cui non è stato eseguito il commit che può essere associato a un BLOB è 100.000.

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 `Put Block`)	Dimensioni massime del BLOB (tramite `Put Block List`)	Dimensioni massime del BLOB tramite un'operazione di scrittura singola (tramite `Put Blob`)
Versione 2019-12-12 e successive	4.000 mebibyte (MiB)	Circa 190,7 tebibyte (TiB) (4.000 MiB × 50.000 blocchi)	5.000 MiB
Versioni da 2016-05-31 a 2019-07-07	100 MiB	Circa 4,75 TiB (100 MiB × 50.000 blocchi)	256 MiB
Versioni precedenti alla versione 2016-05-31	4 MiB	Circa 195 GiB (4 MiB × 50.000 blocchi)	64 MiB

Quando si chiama Put Block List per aggiornare un Blob esistente, le proprietà esistenti e i metadati del Blob vengono sovrascritti. Tuttavia, eventuali snapshot esistenti vengono mantenuti con il Blob. È possibile utilizzare le intestazioni condizionali per eseguire l'operazione solo se viene soddisfatta una determinata condizione.

Se l'operazione Put Block List non riesce a causa di un blocco mancante, è necessario caricare il blocco mancante.

Tutti i blocchi di cui non è stato eseguito il commit vengono sottoposte a Garbage Collection se non sono presenti chiamate riuscite al Put BlockPut Block List BLOB entro una settimana dall'ultima operazione riuscita Put Block . Se il BLOB Put viene chiamato nel BLOB, tutti i blocchi di cui non è stato eseguito il commit vengono raccolti tramite Garbage Collection.

Se i tag vengono forniti nell'intestazione x-ms-tags , devono essere codificati in stringa di query. Le chiavi e i valori dei tag devono essere conformi ai requisiti di denominazione e lunghezza, come specificato in Set Blob Tags. Inoltre, l'intestazione x-ms-tags può contenere tag di dimensioni fino a 2 KiB. Se sono necessari più tag, usare l'operazione Imposta tag BLOB .

Se il BLOB ha un lease attivo, il client deve specificare un ID lease valido nella richiesta per eseguire il commit dell'elenco di blocchi. Se il client non specifica un ID lease o specifica un ID lease non valido, Archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita). Se il client specifica un ID lease ma il BLOB non ha un lease attivo, Archiviazione BLOB restituisce anche il codice di stato 412 (precondizione non riuscita). Se il client specifica un ID lease in un BLOB che non esiste ancora, l'archiviazione BLOB restituisce il codice di stato 412 (Precondizione non riuscita) per le richieste effettuate nella versione 2013-08-15 o successiva. Per le versioni precedenti, l'archiviazione BLOB restituisce il codice di stato 201 (creato).

Se il Blob presenta un lease attivo e si chiama Put Block List per aggiornare il Blob, il lease viene mantenuto nel Blob aggiornato.

Put Block List si applica solo ai Blob in blocchi. La chiamata a Put Block List in un Blob di pagine restituisce il codice di stato 400 (Richiesta non valida).

La sovrascrittura di un BLOB archiviato ha esito negativo e la sovrascrittura di un hot BLOB o cool eredita il livello dal BLOB precedente se l'intestazione x-ms-access-tier non viene fornita.

Fatturazione

Le richieste di determinazione dei prezzi possono provenire dai client che usano le API di archiviazione BLOB, direttamente tramite l'API REST di 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. La tabella seguente illustra la categoria di fatturazione per Put Block List le richieste in base al tipo di account di archiviazione:

Operazione	Tipo di account di archiviazione	Categoria di fatturazione
Put Block List	BLOB in blocchi Premium Utilizzo generico v2 Standard Standard per utilizzo generico v1	Operazioni di scrittura

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

Vedi anche

Informazioni su BLOB in blocchi, BLOB di accodamento e BLOB di pagine
Autorizzare le richieste ad Archiviazione di Azure
Stato e codici errore
Codici di errore del servizio BLOB
Impostare i timeout per le operazioni del servizio BLOB