VENDITE: 1-800-867-1389

Put Block List

Aggiornamento: gennaio 2014

Tramite l'operazione Put Block List viene scritto un Blob specificando l'elenco di ID dei blocchi che lo compongono. Per poter 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.

La richiesta Put Block List può essere costruita nel modo seguente. Si consiglia di utilizzare 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

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

Si noti che l'emulatore di archiviazione supporta solo Blob di dimensioni non superiori a 2 GB.

Per altre informazioni, vedere Uso dell'emulatore di archiviazione di Azure per lo sviluppo e il test.

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

 

Parametro Descrizione

timeout

Facoltativo. Il parametro timeout viene espresso in secondi. Per altre informazioni, vedere Impostazione di timeout per le operazioni del servizio Blob.

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

 

Intestazione della richiesta Descrizione

Authorization

Obbligatorio. Specifica lo schema di autenticazione, il nome dell'account e la firma. Per altre informazioni, vedere Autenticazione per i servizi di archiviazione di Azure.

Date o x-ms-date

Obbligatorio. Specifica l'ora UTC (Coordinated Universal Time) per la richiesta. Per altre informazioni, vedere Autenticazione per i servizi di archiviazione di Azure.

x-ms-version

Obbligatoria per tutte le richieste autenticate. 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. Lunghezza del contenuto della richiesta in byte. Si noti che questa intestazione fa riferimento alla lunghezza del contenuto dell'elenco di blocchi, non al 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).

Si noti che questa intestazione è associata al contenuto della richiesta e non al contenuto del Blob stesso.

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. Si noti che questo hash non viene convalidato, perché gli hash per i singoli blocchi vengono convalidati al 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.

Si noti che a partire dalla versione 2009-09-19, i nomi dei metadati devono essere conformi alle regole di denominazione per gli identificatori C#.

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 KB che viene registrato nei log di analisi quando la registrazione di Analisi archiviazione è abilitata. L'utilizzo di questa intestazione è consigliato per la correlazione tra le attività sul lato client e le richieste ricevute dal server. Per altre informazioni vedere Informazioni sulla registrazione di Analisi archiviazione e l'articolo relativo all'utilizzo di log per tenere traccia delle richiesta di archiviazione nella registrazione di Azure.

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 delle operazioni Get Blob e Get Blob Properties include l'intestazione content-disposition.

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.

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>

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 innanzitutto essere caricato con una chiamata a Put Block, dopodiché rimarrà 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 innanzitutto essere caricato con una chiamata a Put Block, dopodiché rimarrà 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>

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

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

Per informazioni sui codici di stato, vedere Codici ed errori di stato.

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 di valori di data e 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

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.

x-ms-request-id

Questa intestazione identifica in modo univoco la richiesta effettuata e può essere utilizzata per risolvere i problemi relativi alla richiesta. Per altre informazioni, vedere Risoluzione dei problemi relativi alle operazioni dell'API.

x-ms-version

Indica la versione del servizio Blob utilizzata 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.

Response Status:
HTTP/1.1 201 Created

Response Headers:
Transfer-Encoding: chunked
Content-MD5: oafL1+HS78x65+e39PGIIg==
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

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.

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 dei blocchi di cui non è stato eseguito il commit e i rimanenti dall'elenco dei blocchi di è 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.

Il numero massimo di blocchi di cui è possibile eseguire il commit è 50.000 e le dimensioni massime di un Blob di cui è possibile eseguire il commit tramite l'operazione Put Block List è 200 GB. Se si tenta di eseguire il commit di più di 50.000 blocchi, il servizio restituisce il codice di stato 413 (Entità della richiesta troppo grande). Nella risposta vengono restituite informazioni aggiuntive sull'errore, incluso il numero massimo di blocchi consentiti.

Il numero massimo di blocchi di cui non è stato eseguito il commit che è possibile associare a un Blob è 100.000, mentre le dimensioni massime dell'elenco dei blocchi di cui non è stato eseguito il commit sono pari a 400 GB.

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 Put Blob viene chiamato sul Blob, tutti i blocchi di cui non è stato eseguito il commit saranno sottoposti a un'operazione di Garbage Collection.

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

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2014 Microsoft