Put Block List

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, un blocco deve essere stato scritto correttamente nel server in un'operazione put block precedente.

È possibile chiamare Put Block List per aggiornare un Blob caricando solo i blocchi che sono stati modificati ed eseguendo il commit dei blocchi nuovi ed esistenti. È possibile eseguire questa operazione specificando se eseguire il commit di un blocco dall'elenco dei blocchi di cui è stato eseguito il commit o dall'elenco di quelli di cui non è stato eseguito oppure se eseguire il commit della versione del blocco caricata più di recente, indipendentemente dall'elenco a cui appartiene.

Richiesta

La richiesta Put Block List può essere costruita come segue. È consigliato il protocollo 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

URI del servizio di archiviazione emulato

Quando si effettua una richiesta nel servizio di archiviazione emulato, specificare il nome host dell'emulatore e la porta del servizio Blob come 127.0.0.1:10000, seguiti 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 dimensioni BLOB fino a 2 GiB.

Per altre informazioni, vedere Uso della Archiviazione di Azure Emulator per sviluppo e test.

Parametri dell'URI

Nell'URI richiesta è possibile specificare i seguenti parametri aggiuntivi.

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

Intestazioni 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 a 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 a 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 della richiesta in byte. 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 ha esito negativo e restituisce il 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 ha esito negativo e restituisce il 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 avrà esito negativo con 400 (richiesta non valida).

Questa intestazione è supportata nelle versioni 2019-02-02 o successive.
x-ms-blob-cache-control facoltativo. Imposta il controllo della cache del Blob. Se specificata, questa proprietà viene archiviata con il Blob e restituita con una richiesta di lettura.

Se questa 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 specificata, questa proprietà viene archiviata con il Blob e restituita con una richiesta di lettura.

Se il tipo di contenuto non viene specificato, viene impostato sul tipo predefinito, ovvero application/octet-stream.
x-ms-blob-content-encoding facoltativo. Imposta la codifica del contenuto del Blob. Se specificata, questa proprietà viene archiviata con il Blob e restituita con una richiesta di lettura.

Se questa 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 il linguaggio del contenuto del Blob. Se specificata, questa proprietà viene archiviata con il Blob e restituita con una richiesta di lettura.

Se questa 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, poiché gli hash per i singoli blocchi sono stati convalidati quando ogni oggetto è stato caricato.

L'operazione Get BLOB restituisce il valore di questa intestazione nell'intestazione di 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 che vengono sottoposti a commit. Questa intestazione è supportata nelle versioni 2019-02-02 o successive.
x-ms-tags facoltativo. Imposta i tag codificati con stringa di query specificati nel BLOB. Per altre informazioni, vedere le osservazioni. Supportato nella versione 2019-12-12 e versioni 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 KiB registrato nei log di analisi quando la registrazione dell'analisi di archiviazione è abilitata. L'uso di questa intestazione è consigliato per la correlazione delle attività lato client con le richieste ricevute dal server. Per altre informazioni, vedere Informazioni sulla registrazione di Analisi archiviazione e registrazione di Azure: uso dei log per tenere traccia delle richieste di Archiviazione.
x-ms-blob-content-disposition facoltativo. Imposta l'intestazione Content-Disposition del BLOB. Disponibile con la versione 2013-08-15 e successive.

Il campo di intestazione Content-Disposition contiene informazioni aggiuntive su come elaborare il payload di risposta e può inoltre essere utilizzato per collegare metadati aggiuntivi. Ad esempio, se impostato su attachment, indica che l'agente utente non deve visualizzare la risposta, bensì una finestra di dialogo Salva con nome.

La risposta dalle operazioni Get BLOB e Get BLOB Properties include l'intestazione content-disposition.
x-ms-access-tier facoltativo. Versione 2018-11-09 e successive. Indica il livello da impostare in un BLOB. Per i BLOB in blocchi, supportati nell'archiviazione BLOB o in account per utilizzo generico v2 solo con la versione 2018-11-09 e successive. I valori validi per i livelli BLOB in blocchi sono HotArchive/Cool/. Per informazioni dettagliate sulla suddivisione in livelli BLOB in blocchi , vedere Livelli di archiviazione ad accesso frequente, ad accesso sporadico e archivio.
x-ms-immutability-policy-until-date Versione 2020-06-12 e successive. Specifica la data di "conservazione fino a" da impostare nel BLOB. Si tratta della data fino alla quale il BLOB può essere protetto dalla modifica o dall'eliminazione. Segue il formato RFC1123.
x-ms-immutability-policy-mode Versione 2020-06-12 e successive. Specifica la modalità dei criteri di immutabilità da impostare nel BLOB. I valori validi sono unlocked/locked. unlocked indica che l'utente può modificare il criterio aumentando o riducendo la data di conservazione. locked indica che queste azioni non sono consentite.
x-ms-legal-hold Versione 2020-06-12 e successive. Specifica il blocco a fini giudiziari da impostare nel BLOB, i valori validi sono true/false.

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

Corpo della richiesta

Nel corpo della richiesta, è possibile specificare l'elenco di blocchi che il servizio 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 che sono stati modificati, è possibile eseguire il commit di una nuova versione del Blob eseguendo il commit dei nuovi blocchi insieme a quelli 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 l'approccio da utilizzare, specificare l'ID blocco nell'elemento XML appropriato nel corpo della richiesta, come segue:

  • Specificare l'ID blocco nell'elemento Committed per indicare che il servizio Blob deve cercare il blocco denominato unicamente nell'elenco dei blocchi di cui è stato eseguito il commit. Se il blocco non viene trovato nell'elenco dei blocchi di cui è stato eseguito il commit, non verrà scritto come parte del Blob e il servizio Blob restituirà il codice di stato 400 (Richiesta non valida).

  • Specificare l'ID blocco nell'elemento Uncommitted per indicare che il servizio Blob deve cercare il blocco denominato unicamente nell'elenco dei blocchi di cui non è stato eseguito il commit. Se il blocco non viene trovato nell'elenco dei blocchi di cui non è stato eseguito il commit, non verrà scritto come parte del Blob e il servizio Blob restituirà il codice di stato 400 (Richiesta non valida).

  • Specificare l'ID blocco nell'elemento Latest per indicare che il servizio Blob deve cercare il blocco denominato prima nell'elenco dei blocchi di cui non è stato eseguito il commit. 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 dei blocchi di cui non è stato eseguito il commit, il servizio deve cercare il blocco denominato nell'elenco di blocchi di cui è stato eseguito il commit e, se lo trova, scriverlo nel Blob.

Il corpo della richiesta per questa versione di Put Block List presenta 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 illustrare l'utilizzo di Put Block List, supporre di aver caricato tre blocchi di cui 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>  
  

A questo punto, si supponga di voler aggiornare il Blob. Il nuovo Blob presenterà le modifiche seguenti:

  • Un nuovo blocco con ID ANAAAA==. Questo blocco deve essere prima caricato con una chiamata a Put Block e verrà visualizzato nell'elenco dei blocchi di cui non è stato eseguito il commit fino alla chiamata a Put Block List.

  • Versione aggiornata del blocco con ID AZAAAA==. Questo blocco deve essere prima caricato con una chiamata a Put Block e verrà visualizzato nell'elenco dei blocchi di cui non è stato eseguito il commit fino alla 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 verrà 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  
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 di 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 della 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 successive, il valore ETag sarà racchiuso tra virgolette.
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 Date-Time 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 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 dei blocchi e non il contenuto del Blob stesso. 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 e successive, 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 dei 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 Questa intestazione identifica in modo univoco la richiesta effettuata e può essere usata per risolvere i problemi relativi alla richiesta. Per altre informazioni, vedere Risoluzione dei problemi relativi alle operazioni API.
x-ms-version Indica la versione del servizio Blob usata per eseguire la richiesta. Questa intestazione viene restituita per le richieste effettuate nella versione 2009-09-19 e successive.
Date Valore data/ora UTC generato dal servizio che indica l'ora in cui è stata avviata la risposta.
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 e false in caso contrario.
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, in modo che il client possa garantire 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, 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. Questa intestazione 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 usato nelle richieste successive per accedere al BLOB.
x-ms-client-request-id Questa intestazione può essere usata 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 è al massimo 1024 caratteri ASCII visibili. Se l'intestazione x-ms-client-request-id non è presente nella richiesta, questa intestazione non sarà 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

Questa operazione può essere chiamata dal proprietario dell'account e da qualsiasi altro utente che utilizza una firma di accesso condiviso con l'autorizzazione di scrittura per il Blob o il contenitore.

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 .

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ù di una volta, rappresenterà l'intervallo di byte in ognuna di quelle posizioni nell'elenco dei blocchi per il Blob finale di cui è stato eseguito il commit. 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 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 è presente nell'elenco dei blocchi di cui è stato eseguito il commit, ma non in quello dei blocchi di cui non è stato eseguito, Put Block List esegue il commit del blocco dall'elenco dei 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 di blocchi e BLOB consentite dalla versione del servizio:

Versione del servizio Dimensioni massime dei blocchi (tramite Put Block) Dimensioni massime dei BLOB (tramite Put Block List) Dimensioni massime dei BLOB tramite singola operazione di scrittura (tramite Put BLOB)
Versione 2019-12-12 e successive 4000 MiB Circa 190,7 TiB (4000 MiB X 50.000 blocchi) 5000 MiB (anteprima)
Dalla versione 2016-05-31 alla versione 2019-07-07 100 MiB Approssimativamente 4,75 TiB (blocchi di 100 MiB x 50.000) 256 MiB
Versioni precedenti alla 2016-05-31 4 MiB Approssimativamente 195 GiB (blocchi di 4 MiB x 50.000) 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 ha esito negativo a causa di un blocco mancante, è necessario caricarlo.

Tutti i blocchi di cui non è stato eseguito il commit saranno sottoposti a un'operazione di Garbage Collection se nessuna chiamata a Put Block o a Put Block List ha esito positivo nel Blob entro una settimana dopo l'ultima operazione Put Block completata correttamente. Se il BLOB Put viene chiamato nel BLOB, tutti i blocchi di cui non è stato eseguito il commit verranno sottoposto a 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 Imposta tag BLOB. Inoltre, l'intestazione x-ms-tags può contenere tag fino a 2 KiB di dimensioni. Se sono necessari più tag, usare l'operazione Imposta tag BLOB .

Se il Blob presenta 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 ne specifica uno non valido, il servizio Blob restituisce il codice di stato 412 (Condizione preliminare non riuscita). Se il client specifica un ID lease, ma il Blob non presenta un lease attivo, il servizio Blob restituisce il codice di stato 412 (Condizione preliminare non riuscita). Se tramite il client viene specificato un ID lease in un Blob che non esiste ancora, il servizio Blob restituirà il codice di stato 412 (precondizione non riuscita) per le richieste effettuate nella versione 2013-08-15 e successive; per le versioni precedenti, il servizio Blob restituirà 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 eseguirà il failover e la sovrascrittura di un hot/cool BLOB erediterà il livello dal BLOB precedente se l'intestazione x-ms-access-tier non è specificata.

Vedere anche

Informazioni sui BLOB in blocchi, sui BLOB di accodamento e sui BLOB di pagine
Autorizzare le richieste a Archiviazione di Azure
Codici di stato e di errore
Codici di errore del servizio BLOB
Impostazione dei timeout per le operazioni del servizio Blob