Metti blocco dall'URL

Articolo
2025-05-11

L'operazione Put Block From URL crea un nuovo blocco di cui eseguire il commit come parte di un BLOB in cui il contenuto viene letto da un URL. Questa API è disponibile a partire dalla versione 2018-03-28.

Richiesta

È possibile costruire la richiesta di Put Block From URL come indicato di seguito. È consigliabile usare HTTPS. Sostituire myaccount con il nome dell'account di archiviazione:

URI di richiesta del metodo PUT	Versione HTTP
`https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

Richiesta del 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, seguiti dal nome dell'account di archiviazione emulato:

URI di richiesta del metodo PUT	Versione HTTP
`http://127.0.0.1:10000/devstoreaccount1/mycontainer/myblob?comp=block&blockid=id`	HTTP/1.1

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

Parametri URI

Parametro	Descrizione
`blockid`	Obbligatorio. Valore stringa Base64 valido che identifica il blocco. Prima della codifica, la stringa deve essere minore o uguale a 64 byte. Per un BLOB specificato, la lunghezza del valore specificato per il `blockid` parametro deve essere della stessa dimensione per ogni blocco. Nota: la stringa Base64 deve essere codificata in URL.
`timeout`	Opzionale. Il parametro `timeout` è espresso in secondi. Per altre informazioni, vedere Impostare timeout per le operazioni del servizio BLOB.

Header di 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` o `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 ulteriori informazioni, consultare Controllo delle versioni per i servizi di Archiviazione di Azure. Per `Put Block From URL`, la versione deve essere 2018-03-28 o successiva.
`Content-Length`	Obbligatorio. Specifica il numero di byte trasmessi nel corpo della richiesta. Il valore di questa intestazione deve essere impostato su 0. Quando la lunghezza non è 0, l'operazione ha esito negativo con il codice di stato 400 (richiesta non valida).
`x-ms-copy-source:name`	Obbligatorio. Specifica l'URL del BLOB di origine. Il valore può essere un URL di lunghezza massima di 2 kibibyte (KiB) che specifica un BLOB. Il valore deve essere codificato in URL, come apparirebbe in un URI di richiesta. Il BLOB di origine deve essere pubblico o autorizzato tramite una firma di accesso condiviso. Se il BLOB di origine è pubblico, non è necessaria alcuna autorizzazione per eseguire l'operazione. Ecco alcuni esempi di URL di oggetti di origine: - `https://myaccount.blob.core.windows.net/mycontainer/myblob` - `https://myaccount.blob.core.windows.net/mycontainer/myblob?snapshot=<DateTime>` - `https://myaccount.blob.core.windows.net/mycontainer/myblob?versionid=<DateTime>`
`x-ms-copy-source-authorization: <scheme> <signature>`	Opzionale. Specifica lo schema di autorizzazione e la firma per l'origine della copia. Per altre informazioni, vedere Autorizzare le richieste ad Archiviazione di Azure. Nota: per Microsoft Entra è supportato solo uno schema di connessione. Nota: se l'oggetto di origine è accessibile pubblicamente o l'oggetto di origine si trova in un account di archiviazione e si usa un token di firma di accesso condiviso che viene passato `x-ms-copy-source:name`, questa intestazione non è necessaria. Questa intestazione è supportata nelle versioni 2020-10-02 e successive.
`x-ms-source-range`	Opzionale. Carica solo i byte del BLOB nell'URL di origine nell'intervallo specificato. Se questa intestazione non viene specificata, l'intero contenuto del BLOB di origine viene caricato come un singolo blocco. Per altre informazioni, vedere Specificare l'intestazione dell'intervallo per le operazioni del servizio BLOB.
`x-ms-source-content-md5`	Opzionale. Hash MD5 del contenuto del blocco dall'URI. Questo hash viene utilizzato per verificare l'integrità del blocco durante il trasporto dei dati dall'URI. Quando viene specificata questa intestazione, il servizio di archiviazione confronta l'hash del contenuto arrivato dall'origine copia con questo valore di intestazione. Nota: questo hash MD5 non viene archiviato con il BLOB. Se i due hash non corrispondono, l'operazione ha esito negativo con il codice di errore 400 (richiesta non valida).
`x-ms-source-content-crc64`	Opzionale. Hash CRC64 del contenuto del blocco dall'URI. Questo hash viene utilizzato per verificare l'integrità del blocco durante il trasporto dei dati dall'URI. Quando viene specificata questa intestazione, il servizio di archiviazione confronta l'hash del contenuto arrivato dall'origine copia con questo valore di intestazione. Nota: questo hash CRC64 non viene archiviato con il BLOB. Se i due hash non corrispondono, l'operazione ha esito negativo con il codice di errore 400 (richiesta non valida). Se sono presenti entrambe `x-ms-source-content-md5` le intestazioni e `x-ms-source-content-crc64` , la richiesta ha esito negativo con un 400 (Richiesta non valida). Questa intestazione è supportata nelle versioni 2019-02-02 e successive.
`x-ms-encryption-scope`	Opzionale. Indica l'ambito di crittografia da utilizzare per crittografare il contenuto di origine. Questa intestazione è supportata nelle versioni 2019-02-02 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`	Opzionale. Fornisce un valore opaco generato dal client con un limite di caratteri di 1 kibibyte (KiB) registrato nei log quando viene configurata la registrazione. È consigliabile usare questa intestazione per correlare le attività sul lato client alle richieste ricevute dal server. Per altre informazioni, vedere Monitorare l'archiviazione BLOB di Azure.
`x-ms-file-request-intent`	Obbligatorio se `x-ms-copy-source` l'intestazione è un URL di file di Azure e `x-ms-copy-source-authorization` l'intestazione specifica un token OAuth. Il valore accettabile è `backup`. Questa intestazione specifica che il `Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action` o `Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action` deve essere concesso se sono inclusi nei criteri di controllo degli accessi in base al ruolo assegnati all'identità autorizzata usando l'intestazione `x-ms-copy-source-authorization`. Disponibile per la versione 2025-07-05 e successive.

Intestazioni delle richieste (chiavi di crittografia fornite dal cliente)

A partire dalla versione 2019-02-02, le intestazioni seguenti possono essere specificate nella richiesta per crittografare un BLOB con una chiave fornita dal cliente. La crittografia con una chiave fornita dal cliente (e il set di intestazioni corrispondente) è facoltativa.

Header di 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`.

Testo della richiesta

Nessuno.

Esempio di richiesta

Request Syntax:  
PUT https://myaccount.blob.core.windows.net/mycontainer/myblob?comp=block&blockid=AAAAAA%3D%3D HTTP/1.1  
  
Request Headers:  
x-ms-version: 2018-03-28  
x-ms-date: Sat, 31 Mar 2018 14:37:35 GMT    
Authorization: SharedKey myaccount:J4ma1VuFnlJ7yfk/Gu1GxzbfdJloYmBPWlfhZ/xn7GI=  
Content-Length: 0
x-ms-copy-source: https://myaccount.blob.core.windows.net/mycontainer/myblob
x-ms-source-range: bytes=0-499

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 .

Intestazione della risposta	Descrizione
`Content-MD5`	Restituito in modo che il client possa verificare l'integrità del contenuto del messaggio. Il valore di questa intestazione viene calcolato da Archiviazione BLOB. Non è necessariamente uguale al valore specificato nelle intestazioni della richiesta. Per le versioni 2019-02-02 e successive, questa intestazione viene restituita solo quando la richiesta ha questa intestazione.
`x-ms-content-crc64`	Per le versioni 2019-02-02 e successive. Restituito in modo che il client possa verificare l'integrità del contenuto del messaggio. Il valore di questa intestazione viene calcolato da Archiviazione BLOB. Non è necessariamente uguale al valore specificato nelle intestazioni della richiesta. Restituito quando `x-ms-source-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.
`Date`	Valore di data/ora UTC generato dal servizio, che indica l'ora di avvio della 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 del blocco viene crittografato correttamente utilizzando l'algoritmo specificato. In caso contrario, il valore è impostato su `false`.
`x-ms-encryption-key-sha256`	Versione 2019-02-02 e successive. Restituito se la richiesta ha utilizzato una chiave fornita dal cliente per la crittografia, in modo che il client possa garantire che il contenuto della richiesta venga crittografato correttamente utilizzando la chiave fornita.
`x-ms-encryption-scope`	Versione 2019-02-02 e successive. Restituito se la richiesta ha utilizzato un ambito di crittografia, in modo che il client possa garantire che il contenuto della richiesta venga crittografato correttamente utilizzando l'ambito di crittografia.
`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 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: Sat, 31 Mar 2018 23:47:09 GMT  
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0

Autorizzazione

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

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.

Microsoft Entra ID (scelta consigliata)
firme di accesso condiviso
chiave condivisa

Archiviazione di Azure supporta l'uso di Microsoft Entra ID per autorizzare le richieste di accesso 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 al fine di 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 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 From URL 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 quale risorsa può accedere al client, quali autorizzazioni hanno per tali risorse e per quanto tempo la firma di accesso condiviso è valida.

L'operazione di supporta tre tipi di firme di accesso condiviso: delega utente sas, firma di accesso condiviso del servizio e account sas.

Come procedura consigliata per la sicurezza, è consigliabile usare le credenziali di 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 le credenziali di Microsoft Entra per creare una firma di accesso condiviso di delega utente, quando possibile.

Quando l'accesso con chiave condivisa non è consentito per l'account di archiviazione, un token di firma di accesso condiviso del servizio o un token di firma di accesso condiviso dell'account non sarà consentito in una richiesta di archiviazione BLOB. Per altre informazioni, vedere Comprendere in che modo la chiave condivisa influisce sui token di firma di accesso condiviso.

Firma di accesso condiviso di delega utente

Una firma di accesso condiviso di delega utente è protetta con le credenziali di Microsoft Entra e anche dalle autorizzazioni specificate per la firma di accesso condiviso.

Per chiamare l'operazione di 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 di 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.

La chiamata all'operazione di tramite un token di firma di accesso condiviso delegata a un contenitore o a una risorsa BLOB richiede l'autorizzazione di scrittura (w) come parte del token di firma di accesso condiviso del servizio.

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
Metti blocco dall'URL	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 di Put Block From URL supporta 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 della chiave condivisa per l'account di archiviazione, quando possibile. Per altre informazioni, vedere Impedire l'autorizzazione con chiave condivisa.

Osservazioni:

Put Block From URL Carica un blocco per l'inclusione futura in un BLOB in blocchi. Un BLOB in blocchi può includere un massimo di 50.000 blocchi. Ogni blocco può avere una dimensione diversa. La dimensione massima per un blocco caricato è Put Block From URL di 100 mebibyte (MiB). Per caricare blocchi più grandi (fino a 4.000 MiB), consulta Put Block.

Nella versione 2020-10-02 e successive, l'autorizzazione di Microsoft Entra è supportata per l'origine dell'operazione di copia.

Un BLOB può avere un massimo di 100.000 blocchi di cui non è stato eseguito il commit in qualsiasi momento. Se questo massimo viene superato, il servizio restituisce il codice di stato 409 (RequestEntityTooLargeBlockCountExceedsLimit).

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

Versione del servizio	Dimensione massima del blocco (tramite `Put Block From URL`)	Dimensioni massime del BLOB (tramite `Put Block List`)	Dimensioni massime del BLOB tramite una singola operazione di scrittura (tramite `Put Blob From URL`)
Versione 2020-04-08 e successive	4.000 MiB	Circa 190,7 tebibyte (TiB) (4.000 MiB × 50.000 blocchi)	5.000 MiB
Versioni precedenti al 2020-04-08	100 MiB	Circa 4,75 TiB (100 MiB × 50.000 blocchi)	256 MiB

Dopo aver caricato un set di blocchi, è possibile creare o aggiornare il BLOB nel server da questo set chiamando l'operazione Put Block List . Ogni blocco nel set è identificato da un ID blocco univoco all'interno di tale BLOB. L'ambito degli ID di blocco è un determinato BLOB, quindi BLOB diversi possono avere blocchi con gli stessi ID.

Se si chiama Put Block From URL un BLOB che non esiste ancora, viene creato un nuovo BLOB in blocchi con una lunghezza del contenuto pari a 0. Questo BLOB viene enumerato dall'operazione List Blobs , se l'opzione include=uncommittedblobs è specificata. Non viene eseguito il commit del blocco o dei blocchi caricati fino a quando non si chiama Put Block List il nuovo BLOB. Un BLOB creato in questo modo viene mantenuto nel server per una settimana. Se non sono stati aggiunti altri blocchi o non è stato eseguito il commit dei blocchi al BLOB entro tale periodo di tempo, il BLOB viene sottoposto a Garbage Collection.

Un blocco che è stato caricato correttamente con l'operazione Put Block From URL non diventa parte di un BLOB fino a quando non viene eseguito il commit con Put Block List. Prima Put Block List viene chiamato per eseguire il commit del BLOB nuovo o aggiornato, tutte le chiamate a Get Blob restituiscono il contenuto del BLOB senza l'inclusione del blocco di cui non è stato eseguito il commit.

Se carichi un blocco con lo stesso ID blocco di un altro blocco di cui non è stato ancora eseguito il commit, viene eseguito il commit dell'ultimo blocco caricato con tale ID alla successiva operazione riuscita Put Block List .

Dopo Put Block List la chiamata, viene eseguito il commit di tutti i blocchi di cui non è stato eseguito il commit specificati nell'elenco di blocchi come parte del nuovo BLOB. Tutti i blocchi di cui non è stato eseguito il commit che non sono stati specificati nell'elenco di blocchi per il BLOB vengono sottoposti a Garbage Collection e rimossi dall'archiviazione BLOB. Tutti i blocchi di cui non è stato eseguito il commit vengono sottoposti a Garbage Collection anche se non sono presenti chiamate riuscite allo Put Block From URLPut Block List stesso BLOB entro una settimana dall'ultima operazione riuscita Put Block From URL . Se Put Blob viene chiamato sul BLOB, tutti i blocchi di cui non è stato eseguito il commit vengono sottoposti a Garbage Collection.

Se il BLOB ha un lease attivo, il client deve specificare un ID lease valido nella richiesta per scrivere un blocco nel BLOB. 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 lease ma il BLOB non ha un lease attivo, l'archiviazione BLOB restituisce anche il codice di stato 412 (precondizione non riuscita).

Per un BLOB specificato, tutti gli ID blocco devono avere la stessa lunghezza. Se un blocco viene caricato con un ID blocco di lunghezza diversa da quella degli ID blocco per tutti i blocchi di cui non è stato eseguito il commit esistenti, il servizio restituisce il codice di risposta di errore 400 (Richiesta non valida).

La chiamata Put Block From URL non aggiorna l'ora dell'ultima modifica di un BLOB esistente.

La chiamata Put Block From URL a un BLOB di pagine restituisce un errore.

La chiamata Put Block From URL a un BLOB 'archivio' restituisce un errore e la chiamata a un hot BLOB OR cool non modifica il livello BLOB.

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 From URL richieste in base al tipo di account di archiviazione:

Operazione	Tipo di account di archiviazione	Categoria di fatturazione
Put Block From URL (account di destinazione¹)	BLOB in blocchi Premium Utilizzo generico v2 Standard Utilizzo generico v1 Standard	Operazioni di scrittura
Put Block From URL (account di origine²)	BLOB in blocchi Premium Utilizzo generico v2 Standard Utilizzo generico v1 Standard	Operazioni di lettura

¹Al conto di destinazione viene addebitata una transazione per avviare la scrittura.
^{numero arabo}L'account di origine esegue una transazione per ogni richiesta di lettura all'oggetto di origine.

Inoltre, se gli account di origine e di destinazione risiedono in aree diverse (ad esempio, Stati Uniti settentrionali e Stati Uniti meridionali), la larghezza di banda usata per trasferire la richiesta viene addebitata all'account di archiviazione di origine come uscita. L'uscita tra account all'interno della stessa area è gratuita.

Per informazioni sui prezzi per le categorie di fatturazione specificate, vedere Prezzi di Archiviazione BLOB di Azure.

Condividi tramite