Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Calcoli della firma per l'intestazione dell'autorizzazione: trasferimento del payload in più blocchi (caricamento in blocchi) (AWS Signature (versione 4) Come descritto in[Panoramica di](sigv4-auth-using-authorization-header.md#sigv4-auth-header-overview), quando si autenticano le richieste utilizzando l'`Authorization`intestazione, è possibile caricare il payload in blocchi. È possibile inviare dati in blocchi di dimensioni fisse o variabili. Questa sezione descrive il processo di calcolo della firma nel caricamento in blocchi, come si crea il corpo del blocco e come funziona la firma ritardata nel momento in cui si carica per la prima volta il blocco e si invia la firma nel blocco successivo. La sezione di esempio (vedi[Esempio: oggetto PUT](#example-signature-calculations-streaming)) mostra i calcoli delle firme e le `Authorization` intestazioni risultanti che puoi utilizzare come suite di test per verificare il codice. **Nota** Quando si trasferiscono dati in una serie di blocchi, è necessario effettuare una delle seguenti operazioni: Specificate in modo esplicito la lunghezza totale del contenuto (lunghezza dell'oggetto in byte più metadati in ogni blocco) utilizzando l'intestazione HTTP. `Content-Length` A tale scopo, è necessario precalcolare la lunghezza totale del payload, inclusi i metadati inviati in ogni blocco, prima di iniziare la richiesta. Specificate l'intestazione HTTP. `Transfer-Encoding` Se includi l'`Transfer-Encoding`intestazione e specifichi un valore diverso da`identity`, devi omettere l'intestazione. `Content-Length` Per tutte le richieste, è necessario includere l'`x-amz-decoded-content-length`intestazione, specificando la dimensione dell'oggetto in byte. Ogni calcolo della firma del blocco include la firma del blocco precedente. Per iniziare, crei una * firma * iniziale utilizzando solo le intestazioni. La firma iniziale viene utilizzata nel calcolo della firma del primo blocco. Per ogni blocco successivo, si crea una firma in blocco che include la firma del blocco precedente. Pertanto, le firme dei blocchi vengono concatenate; ovvero, la firma del blocco * n * è una funzione * F (blocco n, firma (blocco n-1)). * Il concatenamento garantisce l'invio dei blocchi nell'ordine corretto. Per eseguire un caricamento in blocchi, procedi come segue: 1. Decidi la dimensione del blocco del payload. Ne hai bisogno quando scrivi il codice. La dimensione del blocco deve essere di almeno 8 KB. Consigliamo una dimensione del blocco di almeno 64 KB per prestazioni migliori. Questa dimensione del blocco si applica a tutti i blocchi tranne l'ultimo. L'ultimo blocco inviato può essere inferiore a 8 KB. Se il payload è piccolo e può essere contenuto in un blocco, può essere inferiore agli 8 KB. 1. Crea la firma iniziale da includere nel primo blocco. Per ulteriori informazioni, consulta [Calcolo della firma iniziale](#sigv4-chunked-upload-sig-calculation-chunk0). 1. Crea il primo blocco e trasmettilo in streaming. Per ulteriori informazioni, consulta [Definizione del corpo del blocco](#sigv4-chunked-body-definition). 1. Per ogni blocco successivo, calcola la firma del blocco che include la firma precedente nella stringa che firmi, costruisci il blocco e invialo. Per ulteriori informazioni, consulta [Definizione del corpo del blocco](#sigv4-chunked-body-definition). 1. Inviate l'ultimo blocco aggiuntivo, che è lo stesso degli altri blocchi nella costruzione, ma contiene zero byte di dati. Per ulteriori informazioni, consulta [Definizione del corpo del blocco](#sigv4-chunked-body-definition). ## Calcolo della firma iniziale Il diagramma seguente illustra il processo di calcolo della firma iniziale. ![Il processo di calcolo della firma iniziale.](https://docs.aws.amazon.com/it_it/AmazonS3/latest/developerguide/images/sigV4-auth-header-chunked-seed-signature.png) La tabella seguente descrive le funzioni mostrate nel diagramma. Per queste funzioni devi implementare il codice. | Funzione | Description | | --- | --- | | Lowercase() | Converte la stringa in minuscolo. | | Hex() | Codifica in base 16 minuscola. | | SHA256Hash() | Funzione hash crittografica Secure Hash Algorithm (SHA). | | HMAC-SHA256() | Calcola HMAC utilizzando l'algoritmo SHA256 con la chiave di firma fornita. Questa è la firma definitiva. | | Trim() | Rimuove eventuali spazi bianchi all'inizio o alla fine della stringa. | | UriEncode() | L'URI codifica ogni byte. UriEncode() deve applicare le seguenti regole:+ L'URI codifica ogni byte tranne i caratteri senza riserve: 'A'-'Z', 'a'-'z', '0'-'9', '-', ' . ','\_' e '\~'.
+ Il carattere di spazio è un carattere riservato e deve essere codificato come "%20" (e non come "\+").
+ Ogni byte codificato in URI è formato da una '%' e dal valore esadecimale a due cifre del byte.
+ Le lettere nel valore esadecimale devono essere maiuscole, ad esempio "%1A".
+ Codifica la barra, '/', ovunque tranne nel nome della chiave dell'oggetto. Ad esempio, se il nome della chiave dell'oggetto è `photos/Jan/sample.jpg`, la barra nel nome della chiave non è codificata. Le UriEncode funzioni standard fornite dalla piattaforma di sviluppo potrebbero non funzionare a causa delle differenze di implementazione e della relativa ambiguità nelle RFC sottostanti. Ti consigliamo di scrivere una UriEncode funzione personalizzata per assicurarti che la codifica funzioni.
Di seguito è riportata una funzione example UriEncode () in Java.
public static String UriEncode(CharSequence input, boolean encodeSlash) {
          StringBuilder result = new StringBuilder();
          for (int i = 0; i < input.length(); i++) {
              char ch = input.charAt(i);
              if ((ch >= 'A' && ch <= 'Z') || (ch >= 'a' && ch <= 'z') || (ch >= '0' && ch <= '9') || ch == '_' || ch == '-' || ch == '~' || ch == '.') {
                  result.append(ch);
              } else if (ch == '/') {
                  result.append(encodeSlash ? "%2F" : ch);
              } else {
                  result.append(toHexUTF8(ch));
              }
          }
          return result.toString();
      }
| Per informazioni sul processo di firma, vedere[Calcolo delle firme per l'intestazione di autorizzazione: trasferimento del payload in un unico blocco (AWS Signature (versione 4)](sig-v4-header-based-auth.md). Il processo è lo stesso, tranne per il fatto che la creazione di è `CanonicalRequest` diversa come segue: + Oltre alle intestazioni delle richieste che intendi aggiungere, devi includere le seguenti intestazioni:
HeaderDescription
x-amz-content-sha256Questa intestazione è obbligatoria per tutte le richieste di AWS Signature Version 4. Imposta il valore su STREAMING-AWS4-HMAC-SHA256-PAYLOAD per indicare che la firma copre solo le intestazioni e che non è presente alcun payload.
Content-EncodingImpostare il valore su aws-chunked.
Amazon S3 supporta più valori di codifica dei contenuti. Puoi specificare la codifica dei contenuti personalizzata quando usi l'API di streaming Signature Version 4.
Ad esempio:
Content-Encoding : aws-chunked,gzip

Amazon S3 memorizza l'oggetto risultante senza il aws-chunked valore nell'intestazione. content-encoding Se aws-chunked è l'unico valore che passi nell'content-encodingintestazione, S3 considera l'intestazione vuota e non restituisce questa content-encoding intestazione quando recuperi l'oggetto.
x-amz-decoded-content-length Imposta il valore sulla lunghezza, in byte, dei dati da suddividere in blocchi, senza contare i metadati. Ad esempio, se stai caricando un file da 4 GB, imposta il valore su 4294967296. Questa è la dimensione grezza dell'oggetto da caricare (dati che desideri archiviare in Amazon S3).
Content-LengthImposta il valore sulla dimensione effettiva del corpo HTTP trasmesso, che include la lunghezza dei dati (valore impostato perx-amz-decoded-content-length), più i metadati in blocchi. Ogni blocco contiene metadati, come la firma del blocco precedente. I calcoli dei blocchi sono descritti nella sezione seguente. Se si include l'Transfer-Encodingintestazione e si specifica un valore diverso daidentity, non è necessario includere l'Content-Lengthintestazione.
Invii il primo blocco con la firma iniziale. È necessario costruire il blocco come descritto nella sezione seguente. ## Definizione del corpo del blocco Tutti i blocchi includono alcuni metadati. Ogni blocco deve essere conforme alla seguente struttura: ``` string(IntHexBase({{chunk-size}})) + ";chunk-signature=" + {{signature}} + \r\n + {{chunk-data}} + \r\n ``` Dove: + `IntHexBase()`è una funzione che si scrive per convertire la dimensione di un blocco intero in formato esadecimale. Ad esempio, se la dimensione del blocco è 65536, la stringa esadecimale è «10000". + {{chunk-size}}è la dimensione, in byte, del blocco di dati, senza metadati. Ad esempio, se si carica un oggetto da 65 KB e si utilizza una dimensione del blocco di 64 KB, si caricano i dati in tre blocchi: il primo sarà 64 KB, il secondo 1 KB e l'ultimo blocco con 0 byte. + {{signature}}Per ogni blocco, si calcola la firma utilizzando la seguente stringa da firmare. Per il primo blocco, si utilizza la firma iniziale come firma precedente. ![Il processo di calcolo della firma iniziale che mostra i vari componenti della stringa da firmare.](https://docs.aws.amazon.com/it_it/AmazonS3/latest/developerguide/images/sigV4-auth-header-chunk-signature.png) La dimensione dei dati del blocco finale che invii è 0, sebbene il corpo del blocco contenga ancora metadati, inclusa la firma del blocco precedente. ## Esempio: oggetto PUT È possibile utilizzare gli esempi in questa sezione come riferimento per controllare i calcoli delle firme nel codice. Prima di esaminare gli esempi, tenete presente quanto segue: + I calcoli delle firme in questi esempi utilizzano le seguenti credenziali di sicurezza di esempio.
ParametroValore
AWSAccessKeyIdAKIAIOSFODNN7EXAMPLE
AWSSecretAccessKeywJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
+ Tutti gli esempi utilizzano il timestamp della richiesta 20130524T000000Z (). `Fri, 24 May 2013 00:00:00 GMT` + Tutti `examplebucket` gli esempi utilizzano come nome del bucket. + Si presume che il bucket si trovi nella regione Stati Uniti orientali (Virginia settentrionale) e le credenziali `Scope` e i `Signing Key` calcoli vengono utilizzati `us-east-1` come identificatore della regione. Per ulteriori informazioni consultare l'articolo relativo alle [Regioni ed endpoint](https://docs.aws.amazon.com/general/latest/gr/rande.html#s3_region) nel documento *Riferimenti generali di Amazon Web Services*. + Puoi utilizzare lo stile del percorso o le richieste di stile ospitate virtualmente. Gli esempi seguenti utilizzano richieste di stile ospitate virtualmente, ad esempio: ``` https://examplebucket.s3.amazonaws.com/photos/photo1.jpg ``` Per ulteriori informazioni, consulta [ Virtual Hosting of Buckets ](https://docs.aws.amazon.com/AmazonS3/latest/userguide/VirtualHosting.html) nella * Amazon Simple Storage Service User Guide. * L'esempio seguente invia una `PUT` richiesta per caricare un oggetto. I calcoli delle firme presuppongono quanto segue: + Stai caricando un file di testo da 65 KB e il contenuto del file è una stringa di un carattere composta dalla lettera «a». + La dimensione del blocco è 64 KB. Di conseguenza, il payload viene caricato in tre blocchi, 64 KB, 1 KB e l'ultimo blocco con 0 byte di dati in blocco. + L'oggetto risultante ha il nome della chiave. `chunkObject.txt` + La richiesta viene effettuata `REDUCED_REDUNDANCY` come classe di archiviazione aggiungendo l'intestazione della `x-amz-storage-class` richiesta. Per informazioni sull'azione API, consulta. [ PutObject ](https://docs.aws.amazon.com/AmazonS3/latest/API/API_PutObject.html) La sintassi generale della richiesta è la seguente: ``` PUT /examplebucket/chunkObject.txt HTTP/1.1 Host: s3.amazonaws.com x-amz-date: 20130524T000000Z x-amz-storage-class: REDUCED_REDUNDANCY Authorization: {{SignatureToBeCalculated}} x-amz-content-sha256: STREAMING-AWS4-HMAC-SHA256-PAYLOAD Content-Encoding: aws-chunked x-amz-decoded-content-length: 66560 Content-Length: 66824 {{}} ``` I passaggi seguenti mostrano i calcoli delle firme. 1. **Firma iniziale: crea una stringa da firmare** 1. **CanonicalRequest** ``` PUT /examplebucket/chunkObject.txt content-encoding:aws-chunked content-length:66824 host:s3.amazonaws.com x-amz-content-sha256:STREAMING-AWS4-HMAC-SHA256-PAYLOAD x-amz-date:20130524T000000Z x-amz-decoded-content-length:66560 x-amz-storage-class:REDUCED_REDUNDANCY content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class STREAMING-AWS4-HMAC-SHA256-PAYLOAD ``` Nella richiesta canonica, la terza riga è vuota perché nella richiesta non sono presenti parametri di interrogazione. L'ultima riga è la stringa costante fornita come valore del Payload con hash, che deve essere uguale al valore di. `x-amz-content-sha256 header` 1. **StringToSign** ``` AWS4-HMAC-SHA256 20130524T000000Z 20130524/us-east-1/s3/aws4_request cee3fed04b70f867d036f722359b0b1f2f0e5dc0efadbc082b76c4c60e316455 ``` **Nota** Per informazioni su ciascuna riga della stringa da firmare, consulta il diagramma che spiega il calcolo della firma iniziale. 1. **SigningKey** ``` signing key = HMAC-SHA256(HMAC-SHA256(HMAC-SHA256(HMAC-SHA256("AWS4" + "{{}}","20130524"),"us-east-1"),"s3"),"aws4_request") ``` 1. **Firma del seme** ``` 4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9 ``` 1. **Intestazione di autorizzazione** L'intestazione di autorizzazione risultante è la seguente: ``` AWS4-HMAC-SHA256 Credential=AKIAIOSFODNN7EXAMPLE/20130524/us-east-1/s3/aws4_request,SignedHeaders=content-encoding;content-length;host;x-amz-content-sha256;x-amz-date;x-amz-decoded-content-length;x-amz-storage-class,Signature=4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9 ``` 1. **Blocco 1: (65536 byte, con valore 97 per la lettera «a»)** 1. Stringa in blocchi da firmare: ``` AWS4-HMAC-SHA256-PAYLOAD 20130524T000000Z 20130524/us-east-1/s3/aws4_request 4f232c4386841ef735655705268965c44a0e4690baa4adea153f7db9fa80a0a9 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 bf718b6f653bebc184e1479f1935b8da974d701b893afcf49e701f3e2f9f9c5a ``` **Nota** Per informazioni su ogni riga della stringa da firmare, vedete il diagramma precedente che mostra i vari componenti della stringa da firmare (ad esempio, le ultime tre righe sono, `previous-signature``hash("")`, e`hash(current-chunk-data)`). 1. Firma in blocchi: ``` ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648 ``` 1. Dati in blocco inviati: ``` 10000;chunk-signature=ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648 <65536-bytes> ``` 1. **Chunk 2: (1024 byte, con valore 97 per la lettera 'a')** 1. Stringa in blocchi da firmare: ``` AWS4-HMAC-SHA256-PAYLOAD 20130524T000000Z 20130524/us-east-1/s3/aws4_request ad80c730a21e5b8d04586a2213dd63b9a0e99e0e2307b0ade35a65485a288648 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 2edc986847e209b4016e141a6dc8716d3207350f416969382d431539bf292e4a ``` 1. Firma in blocco: ``` 0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497 ``` 1. Dati in blocco inviati: ``` 400;chunk-signature=0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497 <1024 bytes> ``` 1. **Blocco 3: (dati a 0 byte)** 1. Stringa in blocchi da firmare: ``` AWS4-HMAC-SHA256-PAYLOAD 20130524T000000Z 20130524/us-east-1/s3/aws4_request 0055627c9e194cb4542bae2aa5492e3c1575bbb81b612b7d234b86a503ef5497 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ``` 1. Firma in blocco: ``` b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9 ``` 1. Dati in blocco inviati: ``` 0;chunk-signature=b6c6ea8a5354eaf15b3cb7646744f4275b71ea724fed81ceb9323e279d449df9 ```