Condividi tramite

Metti elenco di blocco

L'operazione Put Block List scrive un blob specificando l'elenco degli ID di blocco che compongono il blob. Per essere scritto come parte di un blob, un blocco deve essere stato scritto con successo sul server in un'operazione precedente di Put Block .

Puoi chiamare Put Block List per aggiornare un blob caricando solo quei blocchi che sono cambiati e poi facendo commit insieme dei blocchi nuovi e esistenti. Puoi farlo specificando se fare commit di un blocco dalla lista di blocchi di commesso o dalla lista di blocchi non commessa, oppure commettere la versione più recente caricata del blocco, a seconda della lista a cui appartiene.

Richiedi

È possibile costruire la richiesta di Put Block List come indicato di seguito. È consigliabile usare HTTPS. Sostituisci myaccount con il nome del tuo account storage:

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

Richiesta del servizio di archiviazione emulata

Quando fai una richiesta contro il servizio di storage emulato, specifica il nome host dell'emulatore e la porta del servizio Blob come 127.0.0.1:10000, seguiti dal nome dell'account di storage emulato:

URI di richiesta del metodo PUT Versione HTTP
http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=blocklist HTTP/1.1

L'emulatore di storage supporta dimensioni di blob fino a 2 gibibyte (GiB) soltanto.

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

Parametri URI

È possibile specificare i parametri aggiuntivi seguenti nell'URI della richiesta:

Parametro Descrizione
timeout Optional. Il parametro timeout è espresso in secondi. Per ulteriori informazioni, vedi Imposta timeout per le operazioni di servizio Blob.

Intestazioni della richiesta

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

Header di 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 oppure x-ms-date Obbligatorio. Specifica l'ora UTC (Coordinated Universal Time) per la richiesta. 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 utilizzare per questa richiesta. Per altre informazioni, vedere Controllo delle versioni per i servizi di archiviazione di Azure.
Content-Length Obbligatorio. La lunghezza del contenuto della richiesta, in byte. Questa intestazione si riferisce alla lunghezza del contenuto della lista dei blocchi, non al blob stesso.
Content-MD5 Optional. Hash MD5 del contenuto della richiesta. Questo hash viene usato 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).

Questo header è associato al contenuto della richiesta, e non al contenuto stesso del blob.
x-ms-content-crc64 Optional. Un hash CRC64 del contenuto della richiesta. Questo hash viene usato 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).

Questo header è associato al contenuto della richiesta, e non al contenuto stesso del blob.

Se sono presenti sia le intestazioni Content-MD5 che x-ms-content-crc64, la richiesta fallisce con un 400 (Richiesta Cattiva).

Questa intestazione è supportata nella versione 2019-02-02 e successive.
x-ms-blob-cache-control Optional. Imposta il controllo della cache del blob. Se questa proprietà è specificata, viene memorizzata con il blob e restituita con una richiesta di lettura.

Se la proprietà non è specificata con la richiesta, viene liberata per il blob se la richiesta ha successo.
x-ms-blob-content-type Optional. Imposta il tipo di contenuto del blob. Se è specificata, questa proprietà viene memorizzata con il blob e restituita con una richiesta di lettura.

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

Se la proprietà non è specificata con la richiesta, viene liberata per il blob se la richiesta ha successo.
x-ms-blob-content-language Optional. Imposta il linguaggio dei contenuti del blob. Se è specificata, questa proprietà viene memorizzata con il blob e restituita con una richiesta di lettura.

Se la proprietà non è specificata con la richiesta, viene liberata per il blob se la richiesta ha successo.
x-ms-blob-content-md5 Optional. Hash MD5 del contenuto del BLOB. Questo hash non viene validato, perché gli hash per i singoli blocchi sono stati convalidati quando ciascuno è stato caricato.

L'operazione Get Blob restituisce il valore di questa intestazione nell'intestazione di risposta Content-MD5.

Se questa proprietà non è specificata con la richiesta, viene liberata per il blob se la richiesta ha successo.
x-ms-meta-name:value Optional. Coppie nome-valore definite dall'utente associate al blob.

Dalla versione 2009-09-19, i nomi dei metadati devono rispettare le regole di denominazione per gli identificatori C#.
x-ms-encryption-scope Optional. Indica l'ambito di crittografia da utilizzare per criptare il blob. Questo valore deve corrispondere all'ambito di crittografia utilizzato per cifrare tutti i blocchi che vengono commsati. Questa intestazione è supportata nella versione 2019-02-02 e successive.
x-ms-encryption-context Optional. Il valore predefinito è "Vuoto". Se il valore è impostato, verrà impostato 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 Optional. Imposta i tag codificati specificati per query stringhe sul blob. Per ulteriori informazioni, consulta la sezione Osservazioni . Supportato nella versione 2019-12-12 e successive.
x-ms-lease-id:<ID> Obbligatorio se il blob ha un contratto d'affitto 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 Optional. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) che viene registrato nei log di analisi quando viene configurato il logging di archiviazione di archiviazione. È consigliabile usare questa intestazione per correlare le attività sul lato client alle richieste ricevute dal server.
x-ms-blob-content-disposition Optional. Imposta l'intestazione del Content-Disposition blob. Disponibile per la versione 2013-08-15 e successive.

Il Content-Disposition campo di intestazione fornisce informazioni aggiuntive su come elaborare il payload di risposta e può essere utilizzato per allegare metadati aggiuntivi. Ad esempio, se è impostato su attachment, questa intestazione indica che l'user-agent non dovrebbe mostrare la risposta, ma dovrebbe invece mostrare una finestra di dialogo Salva Come.

La risposta delle operazioni Get Blob e Get Blob Properties include l'intestazione content-disposizione.
x-ms-access-tier Optional. Versione 2018-11-09 e successive. Indica il livello da impostare su un blob. Per i blob a blocchi, questa intestazione è supportata solo per account di memoria blob o account generici v2 dalla versione 2018-11-09 e successive. I valori validi per i livelli di blob a blocchi sono Hot, Cool, Cold, Smart e Archive.
Nota:Cold Tier è supportato dalla versione 2021-12-02 e successiva. Smart Tier è supportato dalla versione 2026-02-06 e successiva, ed è attualmente in anteprima pubblica.
Per informazioni dettagliate sul tiering dei blob a blocchi, vedi Livelli di archiviazione dei blob.
x-ms-immutability-policy-until-date Versione 2020-06-12 e successive. Specifica la data di conservazione da fissare sul blob. Questa è la data fino alla quale il blob può essere protetto dall'essere modificato o cancellato. Segue RFC1123 formato.
x-ms-immutability-policy-mode Versione 2020-06-12 e successive. Specifica la modalità politica di immutabilità da impostare sul blob. I valori validi sono unlocked e locked. Il unlocked valore indica che gli utenti possono modificare la politica aumentando o diminuendo la data di mantenimento fino a questo. Il locked valore indica che queste azioni sono proibite.
x-ms-legal-hold Versione 2020-06-12 e successive. Specifica il blocco legale da impostare sul blob. I valori validi sono true e false.
x-ms-expiry-option Optional. Versione 2023-08-03 e successive. Specifica l'opzione data di scadenza per la richiesta, vedi ScadenzaOpzione. Questa intestazione è valida per account con namespace gerarchico abilitato.
x-ms-expiry-time Optional. Versione 2023-08-03 e successive. Specifica il momento in cui il blob deve scadere. Il formato per la data di scadenza varia a seconda di x-ms-expiry-option. Per maggiori informazioni, vedi CadenzaOpzione. Questa intestazione è valida per account con namespace gerarchico abilitato.

Il expiryTime già presente su un blob non viene cancellato se la richiesta non contiene un nuovo valore di expiryTime

Questa operazione supporta anche l'uso di intestazioni condizionali per fare commit nella block list solo se viene soddisfatta una condizione specificata. Per ulteriori informazioni, vedi Specifica intestazioni condizionate per le operazioni di Blob Storage.

Intestazioni richieste (chiavi di crittografia fornite dal cliente)

Dalla versione 2019-02-02, puoi specificare le seguenti intestazioni nella richiesta di crittare un blob con una chiave fornita dal cliente. La crittografia con una chiave fornita dal cliente (e il corrispondente insieme di intestazioni) è opzionale.

Header di richiesta Descrizione
x-ms-encryption-key Obbligatorio. La chiave di crittografia AES-256 codificata in Base64.
x-ms-encryption-key-sha256 Obbligatorio. L'hash SHA256 codificato in 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, puoi specificare la lista dei blocchi che Blob Storage dovrebbe controllare per il blocco richiesto. In questo modo, puoi aggiornare un blob esistente inserendo, sostituendo o cancellando singoli blocchi, invece di ricaricare l'intero blob. Dopo aver caricato il blocco o i blocchi che sono cambiati, puoi commettere una nuova versione del blob facendo commit dei nuovi blocchi insieme a quelli esistenti che vuoi mantenere.

Per aggiornare un blob, puoi specificare che il servizio dovrebbe cercare un ID blocco nella lista di blocchi di commessa, nella lista di blocchi non commessa, oppure prima nella lista di blocchi non commessa e poi nella lista di blocchi commessa. Per indicare quale approccio utilizzare, specifica l'ID del blocco che si trova all'interno dell'elemento XML appropriato all'interno del corpo della richiesta, come segue:

  • Specificare l'ID del blocco all'interno dell'elemento Committed per indicare che Blob Storage dovrebbe cercare solo nella lista dei blocchi di compilazione per il blocco nominato. Se il blocco non si trova nella lista di blocchi di commesso, non viene scritto come parte del blob, e Blob Storage restituisce il codice di stato 400 (Richiesta Scorretta).

  • Specificare l'ID del blocco all'interno dell'elemento Uncommitted per indicare che Blob Storage dovrebbe cercare solo nella lista dei blocchi non commessi il blocco nominato. Se il blocco non si trova nella lista dei blocchi non commessi, non viene scritto come parte del blob, e Blob Storage restituisce il codice di stato 400 (Richiesta cattiva).

  • Specificare l'ID del blocco all'interno dell'elemento Latest per indicare che Blob Storage dovrebbe prima cercare nella lista dei blocchi non commessa. Se il blocco si trova nella lista non commessa, quella versione del blocco è l'ultima e dovrebbe essere scritta nel blob. Se il blocco non si trova nella lista non commessa, il servizio dovrebbe cercare nella lista di blocchi commessi il blocco nominato e scrivere quel blocco nel blob se viene trovato.

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

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

Esempio di richiesta

Per dimostrare Put Block List, supponiamo di aver caricato tre blocchi che ora vuoi effettuare. L'esempio seguente commit un nuovo blob indicando che si deve utilizzare la versione più recente di ogni blocco elencato. Non è necessario sapere se questi blocchi sono già stati compiuti.

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>

Poi, supponiamo che tu voglia aggiornare il blob. Il nuovo blob presenta le seguenti modifiche:

  • Un nuovo blocco con ID ANAAAA==. Questo blocco deve prima essere caricato con una chiamata a Put Block, e appare nella lista dei blocchi non commessi fino alla chiamata a Put Block List.

  • Una versione aggiornata del blocco con ID AZAAAA==. Questo blocco deve prima essere caricato con una chiamata a Put Block, e appare nella lista dei blocchi non commessi fino alla chiamata a Put Block List.

  • Rimozione del blocco con l'ID AAAAAA==. Poiché questo blocco non è incluso nella chiamata successiva a Put Block List, il blocco viene effettivamente rimosso dal blob.

Il seguente esempio mostra la chiamata che Put Block List aggiorna 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

La risposta include un codice di stato HTTP e un set di intestazioni di risposta.

Codice di stato

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

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

Intestazioni di risposta

La risposta per questa operazione include le intestazioni seguenti. La risposta può includere anche intestazioni HTTP standard aggiuntive. Tutte le intestazioni standard sono conformi alla specifica del protocollo HTTP/1.1 .

risposta Descrizioni
ETag Il tag entità contiene un valore che il client può utilizzare per eseguire operazioni condizionali GET/PUT utilizzando l'intestazione della If-Match richiesta. Se la versione della richiesta è 2011-08-18 o successiva, il valore ETag è racchiuso tra virgolette.
Last-Modified Data/ora dell'ultima modifica del BLOB. Il formato della data segue RFC 1123. Per ulteriori informazioni, vedi Rappresenta i valori data/ora nelle intestazioni.

Qualsiasi operazione che modifica il blob, incluso un aggiornamento dei metadati o delle proprietà del blob, modifica l'ultimo tempo di modifica del blob.
Content-MD5 Restituito in modo che il client possa verificare l'integrità del contenuto del messaggio. Questo header si riferisce al contenuto della richiesta (in questo caso, all'elenco dei blocchi e non al contenuto stesso del blob stesso). Per la versione 2019-02-02 e successive, questa intestazione viene restituita solo quando la richiesta ha questa intestare.
x-ms-content-crc64 Per la versione 2019-02-02 e successive, questa intestazione viene restituita affinché il client possa verificare l'integrità del contenuto dei messaggi. Questo header si riferisce al contenuto della richiesta (in questo caso, all'elenco dei blocchi e non al contenuto stesso del blob stesso).

Questo header viene restituito quando Content-md5 il header 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 La versione di Blob Storage utilizzata per eseguire la richiesta. Questa intestazione viene restituita per le richieste effettuate contro la versione 2009-09-19 e successive.
Date Un valore 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 a true se il contenuto della richiesta viene criptato con successo utilizzando 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 utilizzato una chiave fornita dal cliente per la crittografia, così il client può assicurarsi che il contenuto della richiesta venga criptato con successo utilizzando la chiave fornita.
x-ms-encryption-scope Versione 2019-02-02 e successive. Questa intestazione viene restituita se la richiesta ha utilizzato un ambito di cifratura, così il client può assicurarsi che il contenuto della richiesta venga criptato con successo utilizzando l'ambito di cifratura.
x-ms-version-id: <DateTime> Versione 2019-12-12 e successive. Restituisce un valore DateTime opaco che identifica in modo univoco il BLOB. Il valore di questo header indica la versione del blob, e può essere utilizzato in 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 di Put Block List come descritto di seguito.

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

Importante

Microsoft consiglia di usare l'ID Microsoft Entra 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 sul servizio BLOB.

Per altre informazioni sull'autorizzazione con 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, un'identità gestita o un'entità servizio di Microsoft Entra per chiamare l'operazione di Put Block List e il ruolo controllo degli accessi in base al ruolo di Azure con privilegi minimi che include questa azione:

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.

Osservazioni:

L'operazione Put Block List impone l'ordine in cui i blocchi devono essere combinati per creare un blob.

Lo stesso ID di blocco può essere specificato più di una volta nell'elenco dei blocchi. Se un ID di blocco viene specificato più di una volta, rappresenta l'intervallo di byte in ciascuna di queste posizioni nella lista dei blocchi per il blob finale commesso. Se un ID blocco appare più di una volta nella lista, entrambe le istanze dell'ID blocco devono essere specificate all'interno della stessa lista di blocchi. In altre parole, entrambe le istanze devono essere specificate all'interno dell'elemento Committed , dell'elemento Uncommitted o dell'elemento Latest .

Con , puoi modificare un blob esistente inserendo, aggiornando o eliminando singoli blocchi senza dover caricare Put Block Listdi nuovo l'intero blob. Puoi specificare gli ID dei blocchi sia dalla lista di blocco attualmente commessi che da quella non commessa per creare un nuovo blob o aggiornare il contenuto di un blob esistente. In questo modo, puoi aggiornare un blob specificando alcuni nuovi blocchi dalla lista di blocchi non commessi e gli altri dalla lista di blocchi commessa, che già fanno parte del blob esistente.

Se un ID blocco è specificato nell'elemento Latest , e lo stesso ID di blocco esiste sia nella lista di blocco commessa che in quella non commessa, Put Block List il blocco viene effettuato in commit dalla lista di blocchi non commessa. Se l'ID blocco esiste nella lista di blocco di commessa ma non in quella non commessa, Put Block List il blocco viene effettuato da una commit di blocco dalla lista di blocchi di commessa.

Ogni blocco in un blob di blocchi può avere dimensioni diverse. Un blocco può includere un massimo di 50.000 blocchi impegnati. Il numero massimo di blocchi non commessi che possono essere associati a un blob è 100.000.

La tabella seguente descrive le dimensioni massime consentite di blocchi e blob, per versione del servizio:

Versione del servizio Dimensione massima del blocco (tramite Put Block) Dimensione massima del blob (tramite Put Block List) Dimensione massima del blob tramite singola operazione di scrittura (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 dal 31-05-2016 al 07-07-2019 100 MiB Circa 4,75 TiB (100 MiB × 50.000 blocchi) 256 MiB
Versioni precedenti al 31-05-2016 4 MiB Circa 195 GiB (4 MiB × 50.000 blocchi) 64 MiB

Quando chiami Put Block List per aggiornare un blob esistente, le proprietà e i metadati esistenti del blob vengono sovrascritti. Tuttavia, eventuali snapshot esistenti vengono conservati con il blob. Puoi usare le intestazioni di richiesta condizionali per eseguire l'operazione solo se una condizione specificata è soddisfatta.

Se l'operazione Put Block List fallisce a causa di un blocco mancante, devi caricare il blocco mancante.

Qualsiasi blocco non impegnato viene raccolta rifiuti se non ci sono chiamate riuscite al Put Block blob o Put Block List sul blob entro una settimana dall'ultima operazione riuscita Put Block . Se Put Blob viene chiamato sul BLOB, tutti i blocchi di cui non è stato eseguito il commit vengono sottoposti a Garbage Collection.

Se i tag sono forniti nell'intestazione x-ms-tags , devono essere codificati in query string. Le chiavi e i valori dei tag devono conformarsi ai requisiti di denominazione e lunghezza, come specificato in Set Blob Tags. Inoltre, l'intestazione x-ms-tags può contenere tag fino a 2 KiB di dimensione. Se sono necessari altri tag, si utilizza l'operazione Set Blob Tag .

Se il blob ha un lease attivo, il client deve specificare un ID di locazione valido nella richiesta per il commit della block list. Se il client non specifica un ID lease o specifica un ID lease non valido, l'archiviazione BLOB restituisce il codice di stato 412 (precondizione non riuscita). Se il client specifica un ID del contratto ma il blob non ha un leasing attivo, Blob Storage restituisce anche il codice di stato 412 (Precondizione fallita). Se il client specifica un ID di locazione su un blob che non esiste ancora, Blob Storage restituisce il codice di stato 412 (Precondizione fallita) per le richieste effettuate rispetto alla versione 2013-08-15 o successiva. Per le versioni precedenti, Blob Storage restituisce il codice di stato 201 (Creato).

Se il blob ha un lease attivo e chiami Put Block List per aggiornarlo, il lease viene mantenuto sul blob aggiornato.

Put Block List Si applica solo ai blob di blocco. Chiamare Put Block List un blob di pagina risulta in codice di stato 400 (Richiesta Sbagliata).

Sovrascrivere un archive blob fallisce. Altrimenti, un blob eredita il tier dal vecchio blob se non viene fornito un x-ms-access-tier header.

Fatturazione

Le richieste di prezzi possono provenire 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 sulla modalità di addebito dell'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 richieste in base al tipo di account di archiviazione:

Operation Tipo di account di archiviazione Categoria di fatturazione
Metti elenco di blocco BLOB in blocchi Premium
Standard a uso generale v2
Standard per utilizzo generico v1		 Operazioni di scrittura

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

Vedere anche

Comprendi i blob di blocco, i blob di appendenza e i blob di pagina
Autorizzare le richieste ad Archiviazione di Azure
Stato e codici errore
Codici di errore del servizio Blob
Imposta timeout per le operazioni di servizio Blob

  • Last updated on