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

# Comportamento di richieste e risposte
<a name="RequestAndResponseBehavior"></a>

I seguenti argomenti descrivono come CloudFront gestisce le richieste e le risposte. 

Puoi scoprire come CloudFront interagisce con Amazon S3 o con origini personalizzate, gestisce vari metodi e intestazioni HTTP, elabora i codici di stato e gestisce la memorizzazione nella cache e le risposte agli errori. 

**Topics**
+ [Come CloudFront elabora le richieste HTTP e HTTPS](HTTPandHTTPSRequests.md)
+ [Comportamento di richieste e risposte per origini Amazon S3](RequestAndResponseBehaviorS3Origin.md)
+ [Comportamento di richieste e risposte per origini personalizzate](RequestAndResponseBehaviorCustomOrigin.md)
+ [Comportamento di richieste e risposte per i gruppi di origine](RequestAndResponseBehaviorOriginGroups.md)
+ [Aggiunta di intestazioni personalizzate alle richieste di origine](add-origin-custom-headers.md)
+ [Come CloudFront elabora le richieste parziali per un oggetto (intervallo GETs)](RangeGETs.md)
+ [In che modo CloudFront elabora i codici di stato HTTP 3xx dalla tua origine](http-3xx-status-codes.md)
+ [In che modo CloudFront elabora i codici di stato HTTP 4xx e 5xx dalla tua origine](HTTPStatusCodes.md)
+ [Generazione di risposte di errore personalizzate](GeneratingCustomErrorResponses.md)

# Come CloudFront elabora le richieste HTTP e HTTPS
<a name="HTTPandHTTPSRequests"></a>

Per le origini di Amazon S3, CloudFront accetta per impostazione predefinita le richieste nei protocolli HTTP e HTTPS per gli oggetti in una CloudFront distribuzione. CloudFront quindi inoltra le richieste al tuo bucket Amazon S3 utilizzando lo stesso protocollo in cui sono state effettuate le richieste. 

Per i server di origine personalizzati, al momento della creazione della distribuzione, puoi specificare il modo in cui CloudFront accede ai server di origine: solo tramite HTTP oppure con il protocollo utilizzato dal visualizzatore. Per ulteriori informazioni su come CloudFront gestisce le richieste HTTP e HTTPS per le origini personalizzate, consulta. [Protocolli](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols)

Per informazioni su come limitare la distribuzione, in modo che gli utenti finali possano accedere agli oggetti solo tramite HTTPS, consulta [Usa HTTPS con CloudFront](using-https.md).

**Nota**  
L'addebito per le richieste HTTPS è superiore al costo delle richieste HTTP. Per ulteriori informazioni sulle tariffe di fatturazione, consulta la pagina [CloudFront dei prezzi](https://aws.amazon.com/cloudfront/#pricing).

# Comportamento di richieste e risposte per origini Amazon S3
<a name="RequestAndResponseBehaviorS3Origin"></a>

Per capire come CloudFront elabora le richieste e le risposte quando usi Amazon S3 come origine, consulta le seguenti sezioni:

**Topics**
+ [In che modo CloudFront elabora e inoltra le richieste alla tua origine Amazon S3](#RequestBehaviorS3Origin)
+ [In che modo CloudFront elabora le risposte dalla tua origine Amazon S3](#ResponseBehaviorS3Origin)

## In che modo CloudFront elabora e inoltra le richieste alla tua origine Amazon S3
<a name="RequestBehaviorS3Origin"></a>

Scopri come CloudFront elabora le richieste dei visualizzatori e le inoltra alla tua origine Amazon S3.

**Contents**
+ [Durata del caching e TTL minimo](#RequestS3Caching)
+ [Indirizzi IP client](#RequestS3IPAddresses)
+ [Richieste GET condizionali](#RequestS3ConditionalGETs)
+ [Cookie](#RequestS3Cookies)
+ [Cross-Origin Resource Sharing (CORS)](#RequestS3-cors)
+ [Richieste GET che includono un corpo](#RequestS3-get-body)
+ [Metodi HTTP](#RequestS3HTTPMethods)
+ [Intestazioni di richiesta HTTP che rimuovono o aggiornano CloudFront](#request-s3-removed-headers)
+ [Lunghezza massima di una richiesta e lunghezza massima di un URL](#RequestS3MaxRequestStringLength)
+ [Stapling OCSP](#request-s3-ocsp-stapling)
+ [Protocolli](#RequestS3Protocol)
+ [Stringhe di query](#RequestS3QueryStrings)
+ [Timeout connessione origine e tentativi](#s3-origin-timeout-attempts)
+ [Timeout di risposta dell'origine](#RequestS3RequestTimeout)
+ [Richieste simultanee per lo stesso oggetto (compressione richieste)](#request-s3-traffic-spikes)

### Durata del caching e TTL minimo
<a name="RequestS3Caching"></a>

Per controllare per quanto tempo gli oggetti rimangono in una CloudFront cache prima di CloudFront inoltrare un'altra richiesta all'origine, puoi:
+ Configurare la tua origine per aggiungere un'intestazione `Cache-Control` o un campo di intestazione `Expires` a ogni oggetto.
+ Specificate un valore per Minimum TTL nei comportamenti CloudFront della cache.
+ Utilizzare il valore di default di 24 ore.

Per ulteriori informazioni, consulta [Gestione della durata di permanenza dei contenuti nella cache (scadenza)](Expiration.md).

### Indirizzi IP client
<a name="RequestS3IPAddresses"></a>

Se un visualizzatore invia una richiesta a CloudFront e non include un'intestazione di `X-Forwarded-For` richiesta, CloudFront ottiene l'indirizzo IP del visualizzatore dalla connessione TCP, aggiunge un'`X-Forwarded-For`intestazione che include l'indirizzo IP e inoltra la richiesta all'origine. Ad esempio, se CloudFront ottiene l'indirizzo IP `192.0.2.2` dalla connessione TCP, inoltra la seguente intestazione all'origine:

`X-Forwarded-For: 192.0.2.2`

Se un visualizzatore invia una richiesta CloudFront e include un'intestazione di `X-Forwarded-For` richiesta, CloudFront ottiene l'indirizzo IP del visualizzatore dalla connessione TCP, lo aggiunge alla fine dell'`X-Forwarded-For`intestazione e inoltra la richiesta all'origine. Ad esempio, se la richiesta del visualizzatore include `X-Forwarded-For: 192.0.2.4,192.0.2.3` e CloudFront ottiene l'indirizzo IP `192.0.2.2` dalla connessione TCP, inoltra l'intestazione seguente all'origine:

`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`

**Nota**  
L'`X-Forwarded-For`intestazione contiene IPv4 indirizzi (come 192.0.2.44) e IPv6 indirizzi (come 2001:0 db 8:85 a3: :8a2e: 0370:7334).

### Richieste GET condizionali
<a name="RequestS3ConditionalGETs"></a>

Quando CloudFront riceve una richiesta per un oggetto scaduto da una cache edge, inoltra la richiesta all'origine Amazon S3 per ottenere la versione più recente dell'oggetto o per ottenere la conferma da Amazon S3 che la cache edge ha già CloudFront la versione più recente. Quando Amazon S3 ha originariamente inviato l'oggetto a CloudFront, includeva un `ETag` valore e un `LastModified` valore nella risposta. Nella nuova richiesta CloudFront inoltrata ad Amazon S3 CloudFront , aggiunge una o entrambe le seguenti intestazioni:
+ Un'intestazione `If-Match` o `If-None-Match` che contiene il valore `ETag` per la versione scaduta dell'oggetto.
+ Un'intestazione `If-Modified-Since` che contiene il valore `LastModified` per la versione scaduta dell'oggetto.

Amazon S3 utilizza queste informazioni per determinare se l'oggetto è stato aggiornato e, quindi, se restituire l'intero oggetto CloudFront o restituire solo un codice di stato HTTP 304 (non modificato).

### Cookie
<a name="RequestS3Cookies"></a>

Amazon S3 non elabora i cookie. Se configuri un comportamento di cache per inoltrare i cookie a un'origine Amazon S3, CloudFront inoltra i cookie, ma Amazon S3 li ignora. Tutte le richieste future per lo stesso oggetto, indipendentemente dalla variazione o meno del cookie, vengono servite dall'oggetto esistente nella cache.

### Cross-Origin Resource Sharing (CORS)
<a name="RequestS3-cors"></a>

Se desideri rispettare CloudFront le impostazioni di condivisione delle risorse tra origini diverse di Amazon S3, configura l'inoltro delle intestazioni selezionate CloudFront ad Amazon S3. Per ulteriori informazioni, consulta [Caching dei contenuti in base alle intestazioni di richiesta](header-caching.md).

### Richieste GET che includono un corpo
<a name="RequestS3-get-body"></a>

Se una `GET` richiesta del visualizzatore include un corpo, CloudFront restituisce un codice di stato HTTP 403 (Forbidden) al visualizzatore.

### Metodi HTTP
<a name="RequestS3HTTPMethods"></a>

Se configuri CloudFront per elaborare tutti i metodi HTTP supportati, CloudFront accetta le seguenti richieste dai visualizzatori e le inoltra alla tua origine Amazon S3:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`

CloudFront memorizza sempre nella cache le risposte e le richieste. `GET` `HEAD` È inoltre possibile configurare CloudFront la memorizzazione nella cache delle risposte alle `OPTIONS` richieste. CloudFront non memorizza nella cache le risposte alle richieste che utilizzano gli altri metodi.

Se desideri utilizzare caricamenti in più parti per aggiungere oggetti a un bucket Amazon S3, devi aggiungere CloudFront un controllo di accesso all'origine (OAC) alla tua distribuzione e fornire all'OAC le autorizzazioni necessarie. Per ulteriori informazioni, consulta [Limitazione dell’accesso a un’origine Amazon S3](private-content-restricting-access-to-s3.md).

**Importante**  
Se configuri CloudFront per accettare e inoltrare ad Amazon S3 tutti i metodi HTTP CloudFront supportati, devi creare un CloudFront OAC per limitare l'accesso ai tuoi contenuti Amazon S3 e concedere all'OAC le autorizzazioni richieste. Ad esempio, se configuri per accettare e CloudFront inoltrare questi metodi perché desideri utilizzare il `PUT` metodo, devi configurare le policy dei bucket di Amazon S3 per gestire le `DELETE` richieste in modo appropriato in modo che gli utenti non possano eliminare le risorse che non desideri. Per ulteriori informazioni, consulta [Limitazione dell’accesso a un’origine Amazon S3](private-content-restricting-access-to-s3.md).

Per informazioni sulle operazioni supportate da Amazon S3 consulta la [documentazione di Amazon S3](https://docs.aws.amazon.com/s3/index.html).

### Intestazioni di richiesta HTTP che rimuovono o aggiornano CloudFront
<a name="request-s3-removed-headers"></a>

CloudFront rimuove o aggiorna alcune intestazioni prima di inoltrare le richieste alla tua origine Amazon S3. Per la maggior parte delle intestazioni questo comportamento corrisponde a quello delle origini personalizzate. Per un elenco completo delle intestazioni delle richieste HTTP e di come CloudFront le elabora, consulta. [Intestazioni e CloudFront comportamento delle richieste HTTP (origini personalizzate e Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior)

### Lunghezza massima di una richiesta e lunghezza massima di un URL
<a name="RequestS3MaxRequestStringLength"></a>

La lunghezza massima di una richiesta, inclusi il percorso, la stringa di query (se presente) e le intestazioni, è di 32.768 byte.

CloudFront costruisce un URL a partire dalla richiesta. La lunghezza massima di questo URL è di 8192 byte.

Se un URL supera la lunghezza massima, CloudFront restituisce il codice di stato HTTP 414 (URI troppo lungo) al visualizzatore. Se una richiesta supera la lunghezza massima a causa del superamento della dimensione dell'intestazione, CloudFront restituisce il codice di stato HTTP 494 al visualizzatore. In entrambi i casi, interrompe CloudFront quindi la connessione TCP al visualizzatore.

### Stapling OCSP
<a name="request-s3-ocsp-stapling"></a>

Quando un visualizzatore invia una richiesta HTTPS per un oggetto CloudFront o deve confermare con l'autorità di certificazione (CA) che il certificato SSL per il dominio non è stato revocato. OCSP stapling velocizza la convalida dei certificati consentendo di CloudFront convalidare il certificato e di memorizzare nella cache la risposta della CA, in modo che il client non debba convalidare il certificato direttamente con la CA.

Il miglioramento delle prestazioni dello stapling OCSP è più pronunciato quando si CloudFront ricevono molte richieste HTTPS per oggetti nello stesso dominio. Ogni server in una edge location di CloudFront deve inviare una richiesta di convalida distinta. Quando CloudFront riceve molte richieste HTTPS per lo stesso dominio, ogni server nell'edge location riceve subito una risposta dalla CA che può inserire in un pacchetto nell'handshake SSL. Quando il visualizzatore ritiene che il certificato sia valido, CloudFront può servire l'oggetto richiesto. Se la tua distribuzione non riceve molto traffico in una edge location di CloudFront , è più probabile che le nuove richieste siano indirizzate a un server che non ha ancora convalidato il certificato presso la CA. In tal caso, il visualizzatore esegue separatamente la fase di convalida e il CloudFront server serve l'oggetto. Tale CloudFront server invia inoltre una richiesta di convalida alla CA, quindi la prossima volta che riceve una richiesta che include lo stesso nome di dominio, riceve una risposta di convalida dalla CA.

### Protocolli
<a name="RequestS3Protocol"></a>

CloudFront inoltra le richieste HTTP o HTTPS al server di origine in base al protocollo della richiesta del visualizzatore, HTTP o HTTPS.

**Importante**  
Se il tuo bucket Amazon S3 è configurato come endpoint di un sito Web, non puoi configurare l'utilizzo di HTTPS CloudFront per comunicare con la tua origine perché Amazon S3 non supporta le connessioni HTTPS in quella configurazione.

### Stringhe di query
<a name="RequestS3QueryStrings"></a>

Puoi configurare se CloudFront inoltrare i parametri della stringa di query alla tua origine Amazon S3. Per ulteriori informazioni, consulta [Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query](QueryStringParameters.md).

### Timeout connessione origine e tentativi
<a name="s3-origin-timeout-attempts"></a>

Il *timeout della connessione Origin* è il numero di secondi che CloudFront attendono quando si tenta di stabilire una connessione all'origine.

*I tentativi di connessione all'origine* sono il numero di volte in cui si CloudFront tenta di connettersi all'origine.

Insieme, queste impostazioni determinano la durata dei CloudFront tentativi di connessione all'origine prima di passare all'origine secondaria (nel caso di un gruppo di origine) o restituire una risposta di errore al visualizzatore. Per impostazione predefinita, CloudFront attende fino a 30 secondi (3 tentativi da 10 secondi ciascuno) prima di tentare di connettersi all'origine secondaria o restituire una risposta di errore. Puoi ridurre questo tempo specificando un timeout di connessione più breve, un numero inferiore di tentativi o entrambi.

Per ulteriori informazioni, consulta [Controllo dei timeout e dei tentativi di origine](high_availability_origin_failover.md#controlling-attempts-and-timeouts).

### Timeout di risposta dell'origine
<a name="RequestS3RequestTimeout"></a>

Il *timeout di risposta origine*, noto anche come *timeout di lettura origine* o *timeout di richiesta origine*, si applica a entrambi i valori seguenti:
+ La quantità di tempo, in secondi, che CloudFront attende una risposta dopo l'inoltro di una richiesta all'origine.
+ La quantità di tempo, in secondi, che CloudFront attende dopo aver ricevuto un pacchetto di risposta dall'origine e prima di ricevere il pacchetto successivo.

CloudFront il comportamento dipende dal metodo HTTP della richiesta del visualizzatore:
+ `GET`e `HEAD` richieste: se l'origine non risponde entro 30 secondi o smette di rispondere per 30 secondi, CloudFront interrompe la connessione. Se il numero specificato di [tentativi di connessione all'origine](DownloadDistValuesOrigin.md#origin-connection-attempts) è superiore a 1, CloudFront riprova per ottenere una risposta completa. CloudFront prova fino a 3 volte, in base al valore dell'impostazione dei *tentativi di connessione di origine*. Se l'origine non risponde durante il terzo tentativo, CloudFront non riprova fino a che non riceve un'altra richiesta per il contenuto sulla stessa origine.
+ `DELETE`,`OPTIONS`, `PATCH``PUT`, e `POST` richieste: se l'origine non risponde entro 30 secondi, CloudFront interrompe la connessione e non riprova a contattare l'origine. Il client può inoltrare nuovamente la richiesta, se necessario.

Non è possibile modificare il timeout di risposta per un'origine Amazon S3 (un bucket S3 che *non* è configurato con l'hosting di siti Web statici).

### Richieste simultanee per lo stesso oggetto (compressione richieste)
<a name="request-s3-traffic-spikes"></a>

Quando una CloudFront edge location riceve una richiesta per un oggetto e l'oggetto non è presente nella cache o l'oggetto memorizzato nella cache è scaduto, invia CloudFront immediatamente la richiesta all'origine. Tuttavia, se ci sono richieste simultanee per lo stesso oggetto, ovvero se richieste aggiuntive per lo stesso oggetto (con la stessa chiave di cache) arrivano all'edge location prima di CloudFront ricevere la risposta alla prima richiesta, si CloudFront interrompe prima di inoltrare le richieste aggiuntive all'origine. Questa breve pausa aiuta a ridurre il carico sull'origine. CloudFront invia la risposta dalla richiesta originale a tutte le richieste ricevute mentre era in pausa. Questa operazione è chiamata *compressione richieste*. Nei CloudFront log, la prima richiesta viene identificata come una `Miss` nel `x-edge-result-type` campo e le richieste compresse vengono identificate come a. `Hit` Per ulteriori informazioni sui CloudFront log, vedere. [CloudFront e registrazione delle funzioni edge](logging.md)

CloudFront comprime solo le richieste che condividono una chiave di [*cache*](understanding-the-cache-key.md). Se le richieste aggiuntive non condividono la stessa chiave di cache perché, ad esempio, hai configurato la cache in base CloudFront alle intestazioni delle richieste o ai cookie o alle stringhe di query, CloudFront inoltra tutte le richieste con una chiave di cache univoca all'origine.

Se desideri impedire la compressione di tutte le richieste, puoi utilizzare la policy della cache gestita `CachingDisabled`, che impedisce anche il caching. Per ulteriori informazioni, consulta [Utilizzo delle policy della cache gestite](using-managed-cache-policies.md).

Se desideri evitare la compressione delle richieste per oggetti specifici, puoi impostare il TTL minimo per il comportamento cache su 0 *e* configurare l’origine in modo che invii `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` o `Cache-Control: s-maxage=0`. Queste configurazioni aumenteranno il carico sull'origine e introdurranno una latenza aggiuntiva per le richieste simultanee che vengono messe in pausa durante l' CloudFront attesa della risposta alla prima richiesta.

**Importante**  
Attualmente, CloudFront non supporta la compressione della richiesta se si abilita l'inoltro dei cookie nella politica della cache, nella [politica di [richiesta di origine](controlling-origin-requests.md) o nelle impostazioni della cache](controlling-the-cache-key.md) legacy.

## In che modo CloudFront elabora le risposte dalla tua origine Amazon S3
<a name="ResponseBehaviorS3Origin"></a>

Scopri come CloudFront elabora le risposte dalla tua origine Amazon S3.

**Contents**
+ [Richieste annullate](#response-s3-canceled-requests)
+ [Intestazioni di risposta HTTP che rimuovono o aggiornano CloudFront](#response-s3-removed-headers)
+ [Dimensione massima del file memorizzabile nella cache](#ResponseS3MaxFileSize)
+ [Reindirizzamenti](#ResponseS3Redirects)

### Richieste annullate
<a name="response-s3-canceled-requests"></a>

Se un oggetto non si trova nella cache edge e se un visualizzatore termina una sessione (ad esempio, chiude un browser) dopo averlo CloudFront recuperato dall'origine ma prima che possa consegnare l'oggetto richiesto, CloudFront non lo memorizza nella cache nell'edge location.

### Intestazioni di risposta HTTP che rimuovono o aggiornano CloudFront
<a name="response-s3-removed-headers"></a>

CloudFront rimuove o aggiorna i seguenti campi di intestazione prima di inoltrare la risposta dall'origine Amazon S3 al visualizzatore: 
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie`— Se configuri CloudFront per inoltrare i cookie, inoltrerà il campo di `Set-Cookie` intestazione ai client. Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`— Se la tua origine Amazon S3 restituisce questo campo di intestazione, CloudFront imposta il valore su `chunked` prima di restituire la risposta al visualizzatore.
+ `Upgrade`
+ `Via`— CloudFront imposta il valore seguente nella risposta al visualizzatore:

  `Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`

  Ad esempio, il valore è simile al seguente:

  `Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`

### Dimensione massima del file memorizzabile nella cache
<a name="ResponseS3MaxFileSize"></a>

La dimensione massima di un corpo di risposta che viene CloudFront salvato nella cache è di 50 GB. Questa dimensione include risposte di trasferimento in blocchi che non specificano il valore di intestazione `Content-Length`.

È possibile utilizzare CloudFront per memorizzare nella cache un oggetto di dimensioni maggiori di tali dimensioni utilizzando le richieste di intervallo per richiedere gli oggetti in parti di dimensioni pari o inferiori a 50 GB ciascuna. CloudFrontmemorizza nella cache queste parti perché ognuna di esse pesa 50 GB o meno. Dopo che il visualizzatore ha recuperato tutte le parti dell'oggetto, può ricostruire l'oggetto originale più grande. Per ulteriori informazioni, consulta [Utilizzare richieste di intervallo per memorizzare nella cache oggetti di grandi dimensioni](RangeGETs.md#cache-large-objects-with-range-requests).

### Reindirizzamenti
<a name="ResponseS3Redirects"></a>

Puoi configurare un bucket Amazon S3 per reindirizzare tutte le richieste a un altro nome host, ovvero un altro bucket Amazon S3 o un server HTTP. Se configuri un bucket per reindirizzare tutte le richieste e se il bucket è l'origine di una CloudFront distribuzione, ti consigliamo di configurare il bucket per reindirizzare tutte le richieste a una CloudFront distribuzione utilizzando il nome di dominio per la distribuzione (ad esempio, d111111abcdef8.cloudfront.net) o un nome di dominio alternativo (un CNAME) associato a una distribuzione (ad esempio, example.com). In caso contrario, le richieste del visualizzatore vengono CloudFront ignorate e gli oggetti vengono serviti direttamente dalla nuova origine.

**Nota**  
Se reindirizzi le richieste a un nome di dominio alternativo, devi anche aggiornare il servizio DNS per il tuo dominio aggiungendo un record CNAME. Per ulteriori informazioni, consulta [Utilizza la funzionalità personalizzata URLs aggiungendo nomi di dominio alternativi () CNAMEs](CNAMEs.md).

Di seguito viene descritto ciò che accade quando configuri un bucket per reindirizzare tutte le richieste:

1. Un visualizzatore (ad esempio un browser) richiede un oggetto da CloudFront.

1. CloudFront inoltra la richiesta al bucket Amazon S3 che è l'origine della tua distribuzione.

1. Amazon S3 restituisce un codice di stato HTTP 301 (Spostato in modo permanente) e la nuova posizione.

1. CloudFront memorizza nella cache il codice di stato del reindirizzamento e la nuova posizione e restituisce i valori al visualizzatore. CloudFront non segue il reindirizzamento per recuperare l'oggetto dalla nuova posizione.

1. Il visualizzatore invia un'altra richiesta per l'oggetto, ma questa volta specifica la nuova posizione da cui è stato ottenuto: CloudFront
   + Se il bucket Amazon S3 reindirizza tutte le richieste a una CloudFront distribuzione, utilizzando il nome di dominio per la distribuzione o un nome di dominio alternativo, CloudFront richiede l'oggetto dal bucket Amazon S3 o dal server HTTP nella nuova posizione. Quando la nuova posizione restituisce l'oggetto, lo restituisce al visualizzatore e lo CloudFront memorizza nella cache in una posizione periferica.
   + Se il bucket Amazon S3 reindirizza le richieste verso un'altra posizione, la seconda richiesta viene ignorata. CloudFront Il bucket Amazon S3 o il server HTTP nella nuova posizione restituiscono l'oggetto direttamente al visualizzatore, in modo che l'oggetto non venga mai memorizzato nella cache edge. CloudFront 

# Comportamento di richieste e risposte per origini personalizzate
<a name="RequestAndResponseBehaviorCustomOrigin"></a>

Per comprendere come CloudFront elabora le richieste e le risposte quando utilizzi origini personalizzate, consulta le seguenti sezioni:

**Topics**
+ [In che modo CloudFront elabora e inoltra le richieste all'origine personalizzata](#RequestBehaviorCustomOrigin)
+ [In che modo CloudFront elabora le risposte dalla tua origine personalizzata](#ResponseBehaviorCustomOrigin)

## In che modo CloudFront elabora e inoltra le richieste all'origine personalizzata
<a name="RequestBehaviorCustomOrigin"></a>

Scopri come CloudFront elabora le richieste degli utenti e le inoltra alla tua origine personalizzata.

**Contents**
+ [Autenticazione](#RequestCustomClientAuth)
+ [Durata del caching e TTL minimo](#RequestCustomCaching)
+ [Indirizzi IP client](#RequestCustomIPAddresses)
+ [Autenticazione SSL lato client](#RequestCustomClientSideSslAuth)
+ [Compression](#RequestCustomCompression)
+ [Richieste condizionali](#RequestCustomConditionalGETs)
+ [Cookie](#RequestCustomCookies)
+ [Cross-Origin Resource Sharing (CORS)](#request-custom-cors)
+ [Encryption (Crittografia)](#RequestCustomEncryption)
+ [Richieste GET che includono un corpo](#RequestCustom-get-body)
+ [Metodi HTTP](#RequestCustomHTTPMethods)
+ [Intestazioni e CloudFront comportamento delle richieste HTTP (origini personalizzate e Amazon S3)](#request-custom-headers-behavior)
+ [Versione HTTP](#RequestCustomHTTPVersion)
+ [Lunghezza massima di una richiesta e lunghezza massima di un URL](#RequestCustomMaxRequestStringLength)
+ [Stapling OCSP](#request-custom-ocsp-stapling)
+ [Connessioni persistenti](#request-custom-persistent-connections)
+ [Protocolli](#RequestCustomProtocols)
+ [Stringhe di query](#RequestCustomQueryStrings)
+ [Timeout connessione origine e tentativi](#custom-origin-timeout-attempts)
+ [Timeout di risposta dell'origine](#request-custom-request-timeout)
+ [Richieste simultanee per lo stesso oggetto (compressione richieste)](#request-custom-traffic-spikes)
+ [`User-Agent` Intestazione](#request-custom-user-agent-header)

### Autenticazione
<a name="RequestCustomClientAuth"></a>

Per inoltrare l’intestazione `Authorization` all’origine, puoi configurare il server di origine per richiedere l’autenticazione client per i seguenti tipi di richieste:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `PATCH`
+ `PUT`
+ `POST`

Per `OPTIONS` le richieste, l'autenticazione del client può essere configurata *solo* se utilizzi le seguenti CloudFront impostazioni:
+ CloudFront è configurato per inoltrare l'`Authorization`intestazione all'origine
+ CloudFront è configurato per *non* memorizzare nella cache la risposta alle richieste `OPTIONS`

Per ulteriori informazioni, consulta [Configura CloudFront per inoltrare l'intestazione `Authorization`](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization).

Puoi utilizzare HTTP o HTTPS per inoltrare le richieste al server di origine. Per ulteriori informazioni, consulta [Usa HTTPS con CloudFront](using-https.md).

### Durata del caching e TTL minimo
<a name="RequestCustomCaching"></a>

Per controllare per quanto tempo i tuoi oggetti rimangono in una CloudFront cache prima di CloudFront inoltrare un'altra richiesta all'origine, puoi:
+ Configurare la tua origine per aggiungere un'intestazione `Cache-Control` o un campo di intestazione `Expires` a ogni oggetto.
+ Specificate un valore per Minimum TTL nei comportamenti CloudFront della cache.
+ Utilizzare il valore di default di 24 ore.

Per ulteriori informazioni, consulta [Gestione della durata di permanenza dei contenuti nella cache (scadenza)](Expiration.md).

### Indirizzi IP client
<a name="RequestCustomIPAddresses"></a>

Se un visualizzatore invia una richiesta a CloudFront e non include un'intestazione di `X-Forwarded-For` richiesta, CloudFront ottiene l'indirizzo IP del visualizzatore dalla connessione TCP, aggiunge un'`X-Forwarded-For`intestazione che include l'indirizzo IP e inoltra la richiesta all'origine. Ad esempio, se CloudFront ottiene l'indirizzo IP `192.0.2.2` dalla connessione TCP, inoltra la seguente intestazione all'origine:

`X-Forwarded-For: 192.0.2.2`

Se un visualizzatore invia una richiesta CloudFront e include un'intestazione di `X-Forwarded-For` richiesta, CloudFront ottiene l'indirizzo IP del visualizzatore dalla connessione TCP, lo aggiunge alla fine dell'`X-Forwarded-For`intestazione e inoltra la richiesta all'origine. Ad esempio, se la richiesta del visualizzatore include `X-Forwarded-For: 192.0.2.4,192.0.2.3` e CloudFront ottiene l'indirizzo IP `192.0.2.2` dalla connessione TCP, inoltra l'intestazione seguente all'origine:

`X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2`

Alcune applicazioni, come i sistemi di bilanciamento del carico (incluso Elastic Load Balancing), i firewall per applicazioni Web, i reverse proxy, i sistemi di prevenzione delle intrusioni e l'API Gateway, aggiungono l'indirizzo IP del server perimetrale che ha inoltrato la richiesta alla fine CloudFront dell'intestazione. `X-Forwarded-For` Ad esempio, se CloudFront include `X-Forwarded-For: 192.0.2.2` una richiesta da inoltrare a ELB e se l'indirizzo IP del server CloudFront edge è 192.0.2.199, la richiesta ricevuta dall'istanza EC2 contiene l'intestazione seguente:

`X-Forwarded-For: 192.0.2.2,192.0.2.199`

**Nota**  
L'`X-Forwarded-For`intestazione contiene IPv4 indirizzi (come 192.0.2.44) e indirizzi (come 2001:0 db 8:85 a3: :8a2e IPv6 : 0370:7334).  
Nota inoltre che l'intestazione può essere modificata da ogni nodo sul percorso del server corrente (). `X-Forwarded-For` CloudFront Per ulteriori informazioni, consulta la sezione 8.1 di [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239). È inoltre possibile modificare l'intestazione utilizzando le funzioni di CloudFront edge computing.

### Autenticazione SSL lato client
<a name="RequestCustomClientSideSslAuth"></a>

CloudFront supporta l'autenticazione TLS reciproca (mTLS) in cui sia il client che il server si autenticano a vicenda tramite certificati. Con MTL configurato, è CloudFront possibile convalidare i certificati client durante l'handshake TLS e, facoltativamente, eseguire Funzioni per implementare una logica di convalida personalizzata. CloudFront 

Per le origini che richiedono certificati lato client quando MTLS non è configurato, elimina la richiesta. CloudFront 

Per ulteriori informazioni sulla configurazione degli MTL, consulta. [Associare una funzione di CloudFront connessione](connection-functions.md)

CloudFront non supporta l'autenticazione client con certificati SSL lato client. Se un'origine richiede un certificato lato client, elimina la richiesta. CloudFront 

### Compression
<a name="RequestCustomCompression"></a>

Per ulteriori informazioni, consulta [Distribuzione di file compressi](ServingCompressedFiles.md). 

### Richieste condizionali
<a name="RequestCustomConditionalGETs"></a>

Quando CloudFront riceve una richiesta per un oggetto scaduto da una cache edge, inoltra la richiesta all'origine per ottenere la versione più recente dell'oggetto o per ottenere la conferma dall'origine che la cache CloudFront edge ha già la versione più recente. In genere, quando l'origine ha inviato l'oggetto per l'ultima volta CloudFront, nella risposta `ETag` includeva un `LastModified` valore, un valore o entrambi i valori. Nella nuova richiesta che CloudFront inoltra all'origine, CloudFront aggiunge uno o entrambi i seguenti elementi:
+ Un'intestazione `If-Match` o `If-None-Match` che contiene il valore `ETag` per la versione scaduta dell'oggetto.
+ Un'intestazione `If-Modified-Since` che contiene il valore `LastModified` per la versione scaduta dell'oggetto.

L'origine utilizza queste informazioni per determinare se l'oggetto è stato aggiornato e, quindi, se restituire l'intero oggetto CloudFront o restituire solo un codice di stato HTTP 304 (non modificato).

**Nota**  
`If-Modified-Since`e le richieste `If-None-Match` condizionali non sono supportate quando CloudFront è configurato per inoltrare i cookie (tutti o un sottoinsieme).  
Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).

### Cookie
<a name="RequestCustomCookies"></a>

È possibile configurare CloudFront l'inoltro dei cookie all'origine. Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).

### Cross-Origin Resource Sharing (CORS)
<a name="request-custom-cors"></a>

Se desideri CloudFront rispettare le impostazioni di condivisione delle risorse tra origini diverse, configura CloudFront l'inoltro dell'`Origin`intestazione all'origine. Per ulteriori informazioni, consulta [Caching dei contenuti in base alle intestazioni di richiesta](header-caching.md).

### Encryption (Crittografia)
<a name="RequestCustomEncryption"></a>

Puoi richiedere ai visualizzatori di utilizzare HTTPS per inviare richieste CloudFront e richiedere di CloudFront inoltrare le richieste all'origine personalizzata utilizzando il protocollo utilizzato dal visualizzatore. Per ulteriori informazioni, vedi le seguenti impostazioni di distribuzione:
+ [Viewer Protocol Policy (Policy protocollo visualizzatore)](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [Protocollo (solo origini personalizzate)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)

CloudFront inoltra le richieste HTTPS al server di origine utilizzando i protocolli SSLv3, TLSv1 .0, TLSv1 .1, TLSv1 .2 e .3. TLSv1 Per le origini personalizzate, puoi scegliere i protocolli SSL che desideri utilizzare CloudFront per comunicare con la tua origine:
+ Se utilizzi la CloudFront console, scegli i protocolli utilizzando le caselle di controllo **Origin SSL Protocols**. Per ulteriori informazioni, consulta [Creazione di una distribuzione](distribution-web-creating-console.md). 
+ Se utilizzi l' CloudFront API, specifica i protocolli utilizzando l'`OriginSslProtocols`elemento. Per ulteriori informazioni, consulta [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html)e [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)nell'*Amazon CloudFront API Reference*.

Se l'origine è un bucket Amazon S3, CloudFront il valore predefinito è .3. TLSv1

**Importante**  
Le altre versioni di SSL e TLS non sono supportate.

Per ulteriori informazioni sull'utilizzo di HTTPS con CloudFront, consulta. [Usa HTTPS con CloudFront](using-https.md) Per un elenco dei codici che CloudFront supportano la comunicazione HTTPS tra i visualizzatori e tra l'origine e l'utente CloudFront, CloudFront consulta. [Protocolli e cifrari supportati tra visualizzatori e CloudFront](secure-connections-supported-viewer-protocols-ciphers.md)

### Richieste GET che includono un corpo
<a name="RequestCustom-get-body"></a>

Se una `GET` richiesta del visualizzatore include un corpo, CloudFront restituisce al visualizzatore un codice di stato HTTP 403 (Proibito).

### Metodi HTTP
<a name="RequestCustomHTTPMethods"></a>

Se configuri CloudFront per elaborare tutti i metodi HTTP che supporta, CloudFront accetta le seguenti richieste dai visualizzatori e le inoltra alla tua origine personalizzata:
+ `DELETE`
+ `GET`
+ `HEAD`
+ `OPTIONS`
+ `PATCH`
+ `POST`
+ `PUT`

CloudFront memorizza sempre nella cache le risposte e le richieste. `GET` `HEAD` È inoltre possibile configurare CloudFront la memorizzazione nella cache delle risposte alle `OPTIONS` richieste. CloudFront non memorizza nella cache le risposte alle richieste che utilizzano gli altri metodi.

Per ulteriori informazioni sulla configurazione relativa all'elaborazione di questi metodi mediante la tua origine personalizzata, consulta la documentazione relativa alla tua origine.

**Importante**  
Se configuri CloudFront per accettare e inoltrare all'origine tutti i metodi HTTP CloudFront supportati, configura il server di origine per gestire tutti i metodi. Ad esempio, se configuri per accettare e CloudFront inoltrare questi metodi perché desideri utilizzarli`POST`, devi configurare il server di origine in modo che gestisca `DELETE` le richieste in modo appropriato, in modo che gli utenti non possano eliminare le risorse che non desideri vengano eliminate. Per ulteriori informazioni, consulta la documentazione relativa al tuo server HTTP.

### Intestazioni e CloudFront comportamento delle richieste HTTP (origini personalizzate e Amazon S3)
<a name="request-custom-headers-behavior"></a>

La tabella che segue elenca le intestazioni di richieste HTTP che è possibile inoltrare alle origini personalizzate e Amazon S3 (con le eccezioni indicate). Per ciascuna intestazione, sono incluse le informazioni seguenti:
+ CloudFront comportamento se non configuri l'intestazione CloudFront per inoltrare l'intestazione all'origine, il che comporta la memorizzazione nella cache degli oggetti in base CloudFront ai valori dell'intestazione.
+ Se è possibile configurare la memorizzazione nella cache degli oggetti in base CloudFront ai valori di intestazione per quell'intestazione. 

  Puoi CloudFront configurare la memorizzazione nella cache degli oggetti in base ai valori nelle `User-Agent` intestazioni `Date` and, ma non è consigliabile. Queste intestazioni hanno molti valori possibili e la memorizzazione nella cache in base ai loro valori CloudFront comporterebbe l'inoltro di un numero significativamente maggiore di richieste all'origine.

Per ulteriori informazioni sul caching in base ai valori di intestazione, consulta [Caching dei contenuti in base alle intestazioni di richiesta](header-caching.md).


| Header | Comportamento se non configuri la memorizzazione nella cache CloudFront in base ai valori di intestazione | Supporto del caching in base ai valori di intestazione | 
| --- | --- | --- | 
|  Intestazioni definite da terzi  |  **Impostazioni della cache legacy**: CloudFront inoltra le intestazioni all'origine.  |  Sì  | 
|  `Accept`  |  CloudFront rimuove l'intestazione.  |  Sì  | 
|  `Accept-Charset`  |  CloudFront rimuove l'intestazione.  |  Sì  | 
|  `Accept-Encoding`  |  Se il valore contiene `gzip` o`br`, CloudFront inoltra un'`Accept-Encoding`intestazione normalizzata all'origine. Per ulteriori informazioni, consultare [Supporto della compressione](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) e [Distribuzione di file compressi](ServingCompressedFiles.md).  |  Sì  | 
|  `Accept-Language`  |  CloudFront rimuove l'intestazione.  |  Sì  | 
|  `Authorization`  |  [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html)  |  Sì  | 
|  `Cache-Control`  |  CloudFront inoltra l'intestazione alla tua origine.  |  No  | 
|  `CloudFront-Forwarded-Proto`  |  CloudFront non aggiunge l'intestazione prima di inoltrare la richiesta all'origine. Per ulteriori informazioni, consulta [Configurazione del caching in base al protocollo della richiesta](header-caching.md#header-caching-web-protocol).  |  Sì  | 
|  `CloudFront-Is-Desktop-Viewer`  |  CloudFront non aggiunge l'intestazione prima di inoltrare la richiesta all'origine. Per ulteriori informazioni, consulta [Configurazione del caching in base al tipo di dispositivo](header-caching.md#header-caching-web-device).  |  Sì  | 
|  `CloudFront-Is-Mobile-Viewer`  |  CloudFront non aggiunge l'intestazione prima di inoltrare la richiesta all'origine. Per ulteriori informazioni, consulta [Configurazione del caching in base al tipo di dispositivo](header-caching.md#header-caching-web-device).  |  Sì  | 
|  `CloudFront-Is-Tablet-Viewer`  |  CloudFront non aggiunge l'intestazione prima di inoltrare la richiesta all'origine. Per ulteriori informazioni, consulta [Configurazione del caching in base al tipo di dispositivo](header-caching.md#header-caching-web-device).  |  Sì  | 
|  `CloudFront-Viewer-Country`  |  CloudFront non aggiunge l'intestazione prima di inoltrare la richiesta all'origine.  |  Sì  | 
|  `Connection`  |  CloudFront sostituisce questa intestazione con `Connection: Keep-Alive` prima di inoltrare la richiesta all'origine.  |  No  | 
|  `Content-Length`  |  CloudFront inoltra l'intestazione alla tua origine.  |  No  | 
|  `Content-MD5`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `Content-Type`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `Cookie`  |  Se configuri CloudFront per inoltrare i cookie, inoltrerà il campo di `Cookie` intestazione alla tua origine. In caso contrario, CloudFront rimuove il campo di `Cookie` intestazione. Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).  |  No  | 
|  `Date`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì, ma non consigliato  | 
|  `Expect`  |  CloudFront rimuove l'intestazione.  |  Sì  | 
|  `From`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `Host`  |  CloudFront imposta il valore sul nome di dominio dell'origine associato all'oggetto richiesto. Non puoi memorizzare nella cache in base all'intestazione Host per Amazon S3 MediaStore o sulle origini.  |  Sì (personalizzata) No (S3 e) MediaStore  | 
|  `If-Match`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `If-Modified-Since`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `If-None-Match`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `If-Range`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `If-Unmodified-Since`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `Max-Forwards`  |  CloudFront inoltra l'intestazione alla tua origine.  |  No  | 
|  `Origin`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `Pragma`  |  CloudFront inoltra l'intestazione alla tua origine.  |  No  | 
|  `Proxy-Authenticate`  |  CloudFront rimuove l'intestazione.  |  No  | 
|  `Proxy-Authorization`  |  CloudFront rimuove l'intestazione.  |  No  | 
|  `Proxy-Connection`  |  CloudFront rimuove l'intestazione.  |  No  | 
|  `Range`  |  CloudFront inoltra l'intestazione alla tua origine. Per ulteriori informazioni, consulta [Come CloudFront elabora le richieste parziali per un oggetto (intervallo GETs)](RangeGETs.md).  |  Sì, per impostazione predefinita  | 
|  `Referer`  |  CloudFront rimuove l'intestazione.  |  Sì  | 
|  `Request-Range`  |  CloudFront inoltra l'intestazione alla tua origine.  |  No  | 
|  `TE`  |  CloudFront rimuove l'intestazione.  |  No  | 
|  `Trailer`  |  CloudFront rimuove l'intestazione.  |  No  | 
|  `Transfer-Encoding`  |  CloudFront inoltra l'intestazione alla tua origine.  |  No  | 
|  `Upgrade`  |  CloudFront rimuove l'intestazione, a meno che tu non abbia stabilito una connessione. WebSocket   |  No (ad eccezione delle WebSocket connessioni)  | 
|  `User-Agent`  |  CloudFront sostituisce il valore di questo campo di intestazione con. `Amazon CloudFront` Se desideri CloudFront memorizzare nella cache i contenuti in base al dispositivo utilizzato dall'utente, consulta. [Configurazione del caching in base al tipo di dispositivo](header-caching.md#header-caching-web-device)  |  Sì, ma non consigliato  | 
|  `Via`  |  CloudFront inoltra l'intestazione all'origine.  |  Sì  | 
|  `Warning`  |  CloudFront inoltra l'intestazione alla tua origine.  |  Sì  | 
|  `X-Amz-Cf-Id`  |  CloudFront aggiunge l'intestazione alla richiesta del visualizzatore prima di inoltrare la richiesta all'origine. Il valore di intestazione contiene una stringa crittografata che identifica in modo univoco la richiesta.  |  No  | 
|  `X-Edge-*`  |  CloudFront rimuove tutte le intestazioni. `X-Edge-*`  |  No  | 
|  `X-Forwarded-For`  |  CloudFront inoltra l'intestazione alla tua origine. Per ulteriori informazioni, consulta [Indirizzi IP client](#RequestCustomIPAddresses).  |  Sì  | 
|  `X-Forwarded-Proto`  |  CloudFront rimuove l'intestazione.  |  No  | 
|  `X-HTTP-Method-Override`  |  CloudFront rimuove l'intestazione.  |  Sì  | 
|  `X-Real-IP`  |  CloudFront rimuove l'intestazione.  |  No  | 

### Versione HTTP
<a name="RequestCustomHTTPVersion"></a>

CloudFront inoltra le richieste all'origine personalizzata utilizzando HTTP/1.1.

### Lunghezza massima di una richiesta e lunghezza massima di un URL
<a name="RequestCustomMaxRequestStringLength"></a>

La lunghezza massima di una richiesta, incluso il percorso, la stringa di query (se presente) e le intestazioni, è di 32.768 byte.

CloudFront costruisce un URL a partire dalla richiesta. La lunghezza massima di questo URL è di 8192 byte.

Se un URL supera la lunghezza massima, CloudFront restituisce il codice di stato HTTP 414 (URI troppo lungo) al visualizzatore. Se una richiesta supera la lunghezza massima a causa del superamento della dimensione dell'intestazione, CloudFront restituisce il codice di stato HTTP 494 al visualizzatore. In entrambi i casi, interrompe CloudFront quindi la connessione TCP al visualizzatore.

### Stapling OCSP
<a name="request-custom-ocsp-stapling"></a>

Quando un visualizzatore invia una richiesta HTTPS per un oggetto, uno dei due CloudFront o il visualizzatore deve confermare con l'autorità di certificazione (CA) che il certificato SSL per il dominio non è stato revocato. OCSP stapling velocizza la convalida dei certificati consentendo di CloudFront convalidare il certificato e di memorizzare nella cache la risposta della CA, in modo che il client non debba convalidare il certificato direttamente con la CA.

Il miglioramento delle prestazioni di OCSP Stapling è maggiore quando CloudFront riceve numerose richieste HTTPS per oggetti nello stesso dominio. Ogni server in una CloudFront edge location deve inviare una richiesta di convalida separata. Quando CloudFront riceve numerose richieste HTTPS per lo stesso dominio, ogni server nella edge location ottiene rapidamente una risposta dalla CA che può "spillare" a un pacchetto nell'handshake SSL; quando il visualizzatore è sicuro della validità del certificato, CloudFront può servire l'oggetto richiesto. Se la distribuzione non riceve molto traffico in una CloudFront edge location, è più probabile che le nuove richieste vengano indirizzate a un server che non ha ancora convalidato il certificato con la CA. In tal caso, il visualizzatore esegue separatamente la fase di convalida e il CloudFront server serve l'oggetto. Tale CloudFront server invia inoltre una richiesta di convalida alla CA, quindi la prossima volta che riceve una richiesta che include lo stesso nome di dominio, riceve una risposta di convalida dalla CA.

### Connessioni persistenti
<a name="request-custom-persistent-connections"></a>

Quando CloudFront riceve una risposta dall'origine, tenta di mantenere la connessione per diversi secondi nel caso in cui arrivi un'altra richiesta durante quel periodo. Una connessione permanente consente di risparmiare il tempo necessario a ristabilire la connessione TCP e a eseguire un altro handshake TLS per le richieste successive. 

Per ulteriori informazioni, incluso il modo in cui configurare la durata delle connessioni permanenti, consulta [Timeout keep-alive (solo origini personalizzate e VPC)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) in questa sezione [Riferimento a tutte le impostazioni di distribuzione](distribution-web-values-specify.md).

### Protocolli
<a name="RequestCustomProtocols"></a>

CloudFront inoltra le richieste HTTP o HTTPS al server di origine in base a quanto segue:
+ Il protocollo della richiesta a cui il visualizzatore invia CloudFront, HTTP o HTTPS.
+ Il valore del campo **Origin Protocol Policy** nella CloudFront console o, se utilizzi l' CloudFront API, l'`OriginProtocolPolicy`elemento nel tipo `DistributionConfig` complesso. Nella CloudFront console, le opzioni sono **Solo HTTP, Solo** **HTTPS** e **Match Viewer**.

Se si specifica **Solo HTTP** o **Solo HTTPS**, CloudFront inoltra le richieste al server di origine utilizzando il protocollo specificato, indipendentemente dal protocollo nella richiesta del visualizzatore.

Se si specifica **Match Viewer**, CloudFront inoltra le richieste al server di origine utilizzando il protocollo nella richiesta del visualizzatore. Nota che CloudFront memorizza l'oggetto nella cache una sola volta anche se i visualizzatori effettuano richieste utilizzando entrambi i protocolli HTTP e HTTPS.

**Importante**  
Se CloudFront inoltra una richiesta all'origine utilizzando il protocollo HTTPS e se il server di origine restituisce un certificato non valido o un certificato autofirmato, CloudFront interrompe la connessione TCP.

Per informazioni su come aggiornare una distribuzione utilizzando la console, consulta CloudFront . [Aggiornamento di una distribuzione](HowToUpdateDistribution.md) Per informazioni su come aggiornare una distribuzione utilizzando l' CloudFront API, consulta [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)*Amazon CloudFront API Reference*. 

### Stringhe di query
<a name="RequestCustomQueryStrings"></a>

Puoi configurare se CloudFront inoltrare i parametri della stringa di query alla tua origine. Per ulteriori informazioni, consulta [Memorizzazione nella cache di contenuti basati su parametri delle stringhe di query](QueryStringParameters.md).

### Timeout connessione origine e tentativi
<a name="custom-origin-timeout-attempts"></a>

Il *timeout della connessione Origin* è il numero di secondi che CloudFront attendono quando si tenta di stabilire una connessione all'origine.

*I tentativi di connessione all'origine* sono il numero di volte in cui si CloudFront tenta di connettersi all'origine.

Insieme, queste impostazioni determinano la durata dei CloudFront tentativi di connessione all'origine prima di passare all'origine secondaria (nel caso di un gruppo di origine) o restituire una risposta di errore al visualizzatore. Per impostazione predefinita, CloudFront attende fino a 30 secondi (3 tentativi da 10 secondi ciascuno) prima di tentare di connettersi all'origine secondaria o restituire una risposta di errore. Puoi ridurre questo tempo specificando un timeout di connessione più breve, un numero inferiore di tentativi o entrambi.

Per ulteriori informazioni, consulta [Controllo dei timeout e dei tentativi di origine](high_availability_origin_failover.md#controlling-attempts-and-timeouts).

### Timeout di risposta dell'origine
<a name="request-custom-request-timeout"></a>

Il *timeout di risposta origine*, noto anche come *timeout di lettura origine* o *timeout di richiesta origine*, si applica a entrambi i valori seguenti:
+ La quantità di tempo, in secondi, che CloudFront attende una risposta dopo l'inoltro di una richiesta all'origine.
+ La quantità di tempo, in secondi, che CloudFront attende dopo aver ricevuto un pacchetto di risposta dall'origine e prima di ricevere il pacchetto successivo.

CloudFront il comportamento dipende dal metodo HTTP della richiesta del visualizzatore:
+ `GET`e `HEAD` richieste: se l'origine non risponde o smette di rispondere entro la durata del timeout di risposta, CloudFront interrompe la connessione. Se il numero specificato di [tentativi di connessione all'origine](DownloadDistValuesOrigin.md#origin-connection-attempts) è superiore a 1, CloudFront riprova per ottenere una risposta completa. CloudFront prova fino a 3 volte, in base al valore dell'impostazione dei *tentativi di connessione di origine*. Se l'origine non risponde durante il terzo tentativo, CloudFront non riprova fino a che non riceve un'altra richiesta per il contenuto sulla stessa origine.
+ `DELETE`,`OPTIONS`, `PATCH``PUT`, e `POST` richieste: se l'origine non risponde per la durata del timeout di lettura, CloudFront interrompe la connessione e non riprova a contattare l'origine. Il client può inoltrare nuovamente la richiesta, se necessario.

  

Per ulteriori informazioni, incluso il modo in cui configurare il timeout di risposta origine, consulta [Timeout di risposta](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).

### Richieste simultanee per lo stesso oggetto (compressione richieste)
<a name="request-custom-traffic-spikes"></a>

Quando una CloudFront edge location riceve una richiesta per un oggetto e l'oggetto non è presente nella cache o l'oggetto memorizzato nella cache è scaduto, invia CloudFront immediatamente la richiesta all'origine. Tuttavia, se ci sono richieste simultanee per lo stesso oggetto, ovvero se richieste aggiuntive per lo stesso oggetto (con la stessa chiave di cache) arrivano all'edge location prima di CloudFront ricevere la risposta alla prima richiesta, si CloudFront interrompe prima di inoltrare le richieste aggiuntive all'origine. Questa breve pausa aiuta a ridurre il carico sull'origine. CloudFront invia la risposta dalla richiesta originale a tutte le richieste ricevute mentre era in pausa. Questa operazione è chiamata *compressione richieste*. Nei CloudFront log, la prima richiesta viene identificata come una `Miss` nel `x-edge-result-type` campo e le richieste compresse vengono identificate come a. `Hit` Per ulteriori informazioni sui CloudFront log, vedere. [CloudFront e registrazione delle funzioni edge](logging.md)

CloudFront comprime solo le richieste che condividono una chiave di [*cache*](understanding-the-cache-key.md). Se le richieste aggiuntive non condividono la stessa chiave di cache perché, ad esempio, hai configurato la cache in base CloudFront alle intestazioni delle richieste o ai cookie o alle stringhe di query, CloudFront inoltra tutte le richieste con una chiave di cache univoca all'origine.

Se desideri impedire la compressione di tutte le richieste, puoi utilizzare la policy della cache gestita `CachingDisabled`, che impedisce anche il caching. Per ulteriori informazioni, consulta [Utilizzo delle policy della cache gestite](using-managed-cache-policies.md).

Se desideri evitare la compressione delle richieste per oggetti specifici, puoi impostare il TTL minimo per il comportamento cache su 0 *e* configurare l’origine in modo che invii `Cache-Control: private`, `Cache-Control: no-store`, `Cache-Control: no-cache`, `Cache-Control: max-age=0` o `Cache-Control: s-maxage=0`. Queste configurazioni aumenteranno il carico sull'origine e introdurranno una latenza aggiuntiva per le richieste simultanee che vengono messe in pausa durante l' CloudFront attesa della risposta alla prima richiesta.

**Importante**  
Attualmente, CloudFront non supporta la compressione della richiesta se si abilita l'inoltro dei cookie nella politica della cache, nella [politica di [richiesta di origine](controlling-origin-requests.md) o nelle impostazioni della cache](controlling-the-cache-key.md) legacy.

### `User-Agent` Intestazione
<a name="request-custom-user-agent-header"></a>

Se desideri CloudFront memorizzare nella cache diverse versioni dei tuoi oggetti in base al dispositivo utilizzato dall'utente per visualizzare i tuoi contenuti, ti consigliamo di configurare l'inoltro CloudFront di una o più delle seguenti intestazioni all'origine personalizzata:
+ `CloudFront-Is-Desktop-Viewer`
+ `CloudFront-Is-Mobile-Viewer`
+ `CloudFront-Is-SmartTV-Viewer`
+ `CloudFront-Is-Tablet-Viewer`

In base al valore dell'`User-Agent`intestazione, CloudFront imposta il valore di queste intestazioni su `true` o `false` prima di inoltrare la richiesta all'origine. Se il dispositivo ricade in più di una categoria, allora più di un valore potrebbe essere `true`. Ad esempio, per alcuni dispositivi tablet, CloudFront potrebbe impostare `CloudFront-Is-Mobile-Viewer` e `CloudFront-Is-Tablet-Viewer` su `true`. Per ulteriori informazioni sulla configurazione della cache in base CloudFront alle intestazioni delle richieste, consulta. [Caching dei contenuti in base alle intestazioni di richiesta](header-caching.md)

Puoi CloudFront configurare la memorizzazione nella cache degli oggetti in base ai valori nell'`User-Agent`intestazione, ma non è consigliabile. L'`User-Agent`intestazione ha molti valori possibili e la memorizzazione nella cache basata su tali valori CloudFront comporterebbe l'inoltro di un numero significativamente maggiore di richieste all'origine. 

Se non configuri CloudFront per memorizzare nella cache gli oggetti in base ai valori dell'`User-Agent`intestazione, CloudFront aggiunge un'`User-Agent`intestazione con il seguente valore prima di inoltrare una richiesta all'origine:

`User-Agent = Amazon CloudFront`

CloudFront aggiunge questa intestazione indipendentemente dal fatto che la richiesta del visualizzatore includa un'intestazione. `User-Agent` Se la richiesta del visualizzatore include un'`User-Agent`intestazione, CloudFront la rimuove.

## In che modo CloudFront elabora le risposte dalla tua origine personalizzata
<a name="ResponseBehaviorCustomOrigin"></a>

Scopri come CloudFront elabora le risposte dalla tua origine personalizzata.

**Contents**
+ [Risposte `100 Continue`](#Response100Continue)
+ [Caching](#ResponseCustomCaching)
+ [Richieste annullate](#response-custom-canceled-requests)
+ [Negoziazione di contenuto](#ResponseCustomContentNegotiation)
+ [Cookie](#ResponseCustomCookies)
+ [Connessioni TCP interrotte](#ResponseCustomDroppedTCPConnections)
+ [Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono](#ResponseCustomRemovedHeaders)
+ [Dimensione massima del file memorizzabile nella cache](#ResponseCustomMaxFileSize)
+ [Origine non disponibile](#ResponseCustomOriginUnavailable)
+ [Reindirizzamenti](#ResponseCustomRedirects)
+ [`Transfer-Encoding` Intestazione](#ResponseCustomTransferEncoding)

### Risposte `100 Continue`
<a name="Response100Continue"></a>

La tua origine non può inviare più di una risposta di 100-Continue a. CloudFront Dopo la prima risposta 100-Continue, CloudFront si aspetta una risposta HTTP 200 OK. Se Origin invia un'altra risposta 100-Continue dopo la prima, CloudFront restituirà un errore.

### Caching
<a name="ResponseCustomCaching"></a>
+ Accertati che il server di origine imposti valori validi e accurati per i campi di intestazione `Date` e `Last-Modified`.
+ CloudFront normalmente rispetta un'`Cache-Control: no-cache`intestazione nella risposta dall'origine. Per un'eccezione, consulta [Richieste simultanee per lo stesso oggetto (compressione richieste)](#request-custom-traffic-spikes).

### Richieste annullate
<a name="response-custom-canceled-requests"></a>

Se un oggetto non si trova nella cache edge e se un visualizzatore termina una sessione (ad esempio, chiude un browser) dopo aver CloudFront recuperato l'oggetto dall'origine ma prima che possa consegnare l'oggetto richiesto, CloudFront non memorizza l'oggetto nella cache dell'edge location.

### Negoziazione di contenuto
<a name="ResponseCustomContentNegotiation"></a>

Se la tua origine ritorna `Vary:*` nella risposta e se il valore di **Minimum TTL** per il comportamento della cache corrispondente è **0**, CloudFront memorizza l'oggetto nella cache ma inoltra comunque ogni richiesta successiva dell'oggetto all'origine per confermare che la cache contiene la versione più recente dell'oggetto. CloudFront non include intestazioni condizionali, come o. `If-None-Match` `If-Modified-Since` Di conseguenza, la tua origine restituisce l'oggetto a CloudFront in risposta a ogni richiesta.

Se la tua origine ritorna `Vary:*` nella risposta e se il valore di **Minimum TTL** per il comportamento della cache corrispondente è qualsiasi altro valore, CloudFront elabora l'`Vary`intestazione come descritto in. [Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono](#ResponseCustomRemovedHeaders)

### Cookie
<a name="ResponseCustomCookies"></a>

Se abiliti i cookie per un comportamento nella cache e se l'origine restituisce i cookie con un oggetto, CloudFront memorizza nella cache sia l'oggetto che i cookie. Nota che ciò riduce la capacità di memorizzazione nella cache per un oggetto. Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).

### Connessioni TCP interrotte
<a name="ResponseCustomDroppedTCPConnections"></a>

Se la connessione TCP tra CloudFront e l'origine si interrompe mentre l'origine restituisce un oggetto CloudFront, CloudFront il comportamento dipende dal fatto che l'origine abbia incluso un'`Content-Length`intestazione nella risposta:
+ **Intestazione Content-Length**: CloudFront restituisce l'oggetto al visualizzatore non appena quest'ultimo lo riceve dall'origine. Tuttavia, se il valore dell'`Content-Length`intestazione non corrisponde alla dimensione dell'oggetto, CloudFront non memorizza l'oggetto nella cache.
+ **Transfer-Encoding: Chunked**: CloudFront restituisce l'oggetto al visualizzatore man mano che lo ottiene dall'origine. Tuttavia, se la risposta suddivisa in blocchi non è completa, l'oggetto non viene memorizzato nella cache. CloudFront 
+ **Nessuna intestazione Content-Length**: CloudFront restituisce l'oggetto al visualizzatore e lo memorizza nella cache, ma l'oggetto potrebbe non essere completo. Senza un'intestazione `Content-Length`, CloudFront non è in grado di determinare se la connessione TCP è stata interrotta per errore o intenzionalmente.

Si consiglia di configurare il server HTTP per aggiungere un'`Content-Length`intestazione per impedire CloudFront la memorizzazione nella cache di oggetti parziali.

### Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono
<a name="ResponseCustomRemovedHeaders"></a>

CloudFront rimuove o aggiorna i seguenti campi di intestazione prima di inoltrare la risposta dall'origine al visualizzatore: 
+ `Set-Cookie`— Se configuri CloudFront per inoltrare i cookie, inoltrerà il campo di `Set-Cookie` intestazione ai client. Per ulteriori informazioni, consulta [Caching dei contenuti basati su cookie](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`— Se la tua origine restituisce questo campo di intestazione, CloudFront imposta il valore su `chunked` prima di restituire la risposta allo spettatore.
+ `Upgrade`
+ `Vary` - Tieni presente quanto segue:
  + Se configuri CloudFront per inoltrare qualsiasi intestazione specifica del dispositivo all'origine (`CloudFront-Is-Desktop-Viewer`,, `CloudFront-Is-Mobile-Viewer``CloudFront-Is-SmartTV-Viewer`,`CloudFront-Is-Tablet-Viewer`) e configuri l'origine per tornare a CloudFront, CloudFront ritorna `Vary:User-Agent` al visualizzatore. `Vary:User-Agent` Per ulteriori informazioni, consulta [Configurazione del caching in base al tipo di dispositivo](header-caching.md#header-caching-web-device).
  + Se configuri l'origine per includere una delle due `Accept-Encoding` o `Cookie` nell'`Vary`intestazione, CloudFront include i valori nella risposta al visualizzatore.
  + Se configuri CloudFront per inoltrare le intestazioni all'origine e se configuri l'origine per restituire i nomi delle intestazioni CloudFront nell'`Vary`intestazione (ad esempio,`Vary:Accept-Charset,Accept-Language`), CloudFront restituisce l'`Vary`intestazione con quei valori al visualizzatore.
  + Per informazioni su come CloudFront elabora un valore di `*` nell'intestazione, consulta`Vary`. [Negoziazione di contenuto](#ResponseCustomContentNegotiation)
  + Se configuri l'origine per includere altri valori nell'`Vary`intestazione, CloudFront rimuove i valori prima di restituire la risposta al visualizzatore.
+ `Via`— CloudFront imposta il valore seguente nella risposta al visualizzatore:

  `Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`

  Ad esempio, il valore è simile al seguente:

  `Via: 1.1 1026589cc7887e7a0dc7827b4example.cloudfront.net (CloudFront)`

### Dimensione massima del file memorizzabile nella cache
<a name="ResponseCustomMaxFileSize"></a>

La dimensione massima di un corpo di risposta che viene CloudFront salvato nella cache è di 50 GB. Questa dimensione include risposte di trasferimento in blocchi che non specificano il valore di intestazione `Content-Length`.

È possibile utilizzare CloudFront per memorizzare nella cache un oggetto di dimensioni maggiori di tali dimensioni utilizzando le richieste di intervallo per richiedere gli oggetti in parti di dimensioni pari o inferiori a 50 GB ciascuna. CloudFrontmemorizza nella cache queste parti perché ognuna di esse pesa 50 GB o meno. Dopo che il visualizzatore ha recuperato tutte le parti dell'oggetto, può ricostruire l'oggetto originale più grande. Per ulteriori informazioni, consulta [Utilizzare richieste di intervallo per memorizzare nella cache oggetti di grandi dimensioni](RangeGETs.md#cache-large-objects-with-range-requests).

### Origine non disponibile
<a name="ResponseCustomOriginUnavailable"></a>

Se il server di origine non è disponibile e CloudFront riceve una richiesta per un oggetto che si trova nella cache edge ma che è scaduto (ad esempio, perché è trascorso il periodo di tempo specificato nella `Cache-Control max-age` direttiva), CloudFront fornisce la versione scaduta dell'oggetto o visualizza una pagina di errore personalizzata. Per ulteriori informazioni sul CloudFront comportamento quando hai configurato pagine di errore personalizzate, consulta. [In che modo CloudFront elabora gli errori quando sono state configurate pagine di errore personalizzate](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages) 

In alcuni casi, un oggetto che viene richiesto raramente viene rimosso e non è più disponibile nella cache edge. CloudFront non può servire un oggetto che è stato sfrattato.

### Reindirizzamenti
<a name="ResponseCustomRedirects"></a>

Se modifichi la posizione di un oggetto nel server di origine, puoi configurare il tuo server Web per reindirizzare le richieste alla nuova posizione. Dopo aver configurato il reindirizzamento, la prima volta che un visualizzatore invia una richiesta per l'oggetto, CloudFront invia la richiesta all'origine e l'origine risponde con un reindirizzamento (ad esempio,). `302 Moved Temporarily` CloudFront memorizza nella cache il reindirizzamento e lo restituisce al visualizzatore. CloudFront non segue il reindirizzamento. 

Puoi configurare il server Web per reindirizzare le richieste a una delle seguenti posizioni:
+ Il nuovo URL dell'oggetto sul server di origine. Quando il visualizzatore segue il reindirizzamento al nuovo URL, lo ignora CloudFront e passa direttamente all'origine. Di conseguenza, ti consigliamo di non reindirizzare le richieste al nuovo URL dell’oggetto sull’origine.
+ Il nuovo CloudFront URL per l'oggetto. Quando il visualizzatore invia la richiesta che contiene il nuovo CloudFront URL, CloudFront ottiene l'oggetto dalla nuova posizione sull'origine, lo memorizza nella cache nella posizione periferica e restituisce l'oggetto al visualizzatore. Le richieste successive per l'oggetto saranno servite dalla edge location. In questo modo, si evita la latenza e il carico associati ai visualizzatori che richiedono l'oggetto dall'origine. Tuttavia, ogni nuova richiesta per l'oggetto comporta spese per due richieste a CloudFront.

### `Transfer-Encoding` Intestazione
<a name="ResponseCustomTransferEncoding"></a>

CloudFront supporta solo il `chunked` valore dell'intestazione. `Transfer-Encoding` Se l'origine viene restituita`Transfer-Encoding: chunked`, CloudFront restituisce l'oggetto al client non appena l'oggetto viene ricevuto nell'edge location e memorizza l'oggetto nella cache in formato a blocchi per le richieste successive.

Se il visualizzatore effettua una `Range GET` richiesta e l'origine viene restituita`Transfer-Encoding: chunked`, CloudFront restituisce l'intero oggetto al visualizzatore anziché l'intervallo richiesto.

Ti consigliamo di utilizzare la codifica Chunked se la lunghezza del contenuto della tua risposta non può essere predeterminata. Per ulteriori informazioni, consulta [Connessioni TCP interrotte](#ResponseCustomDroppedTCPConnections). 

# Comportamento di richieste e risposte per i gruppi di origine
<a name="RequestAndResponseBehaviorOriginGroups"></a>

Le richieste a un gruppo di origine funzionano allo stesso modo delle richieste a un'origine non impostata come gruppo di origine, tranne quando è presente un failover di origine. Come per qualsiasi altra origine, quando CloudFront riceve una richiesta e il contenuto è già memorizzato nella cache in una posizione periferica, il contenuto viene fornito agli utenti dalla cache. Quando c'è un errore nella cache e l'origine è un gruppo di origine, le richieste dei visualizzatori vengono inoltrate all'origine primaria nel gruppo di origine.

Il comportamento di richiesta e risposta per l'origine primaria è uguale a quella per un'origine che non è inclusa in un gruppo di origine. Per ulteriori informazioni, consulta [Comportamento di richieste e risposte per origini Amazon S3](RequestAndResponseBehaviorS3Origin.md) e [Comportamento di richieste e risposte per origini personalizzate](RequestAndResponseBehaviorCustomOrigin.md).

I seguenti descrivono il comportamento per il failover di origine quando l'origine primaria restituisce i codici di stato HTTP specifici:
+ Codice di stato HTTP 2xx (operazione riuscita): CloudFront memorizza il file nella cache e lo restituisce al visualizzatore.
+ Codice di stato HTTP 3xx (reindirizzamento): CloudFront restituisce il codice di stato al visualizzatore.
+ Codice di stato HTTP 4xx o 5xx (errore client/server): se il codice di stato restituito è stato configurato per il failover, CloudFront invia la stessa richiesta all'origine secondaria nel gruppo di origine.
+ Codice di stato HTTP 4xx o 5xx (errore client/server): se il codice di stato restituito non è stato configurato per il failover, restituisce l'errore al visualizzatore. CloudFront 

CloudFront esegue il failover sull'origine secondaria solo quando il metodo HTTP della richiesta del visualizzatore è, o. `GET` `HEAD` `OPTIONS` CloudFront non esegue il failover quando il visualizzatore invia un metodo HTTP diverso (ad esempio `POST``PUT`, e così via).

Quando CloudFront invia una richiesta a un'origine secondaria, il comportamento di risposta è lo stesso di un' CloudFront origine che non appartiene a un gruppo di origine.

Per ulteriori informazioni sui gruppi di origine, consulta [Ottimizza l'alta disponibilità con il failover di CloudFront origine](high_availability_origin_failover.md).

# Aggiunta di intestazioni personalizzate alle richieste di origine
<a name="add-origin-custom-headers"></a>

Puoi CloudFront configurare l'aggiunta di intestazioni personalizzate alle richieste inviate all'origine. Puoi utilizzare intestazioni personalizzate per inviare e raccogliere informazioni dall’origine che non si ottengono con richieste tipiche del visualizzatore. Puoi persino personalizzare le intestazioni per ogni origine. CloudFrontsupporta intestazioni personalizzate per origini personalizzate e origini Amazon S3.

**Contents**
+ [Casi d’uso](#add-origin-custom-headers-use-cases)
+ [Configura CloudFront per aggiungere intestazioni personalizzate alle richieste di origine](#add-origin-custom-headers-configure)
+ [Intestazioni personalizzate che CloudFront non possono essere aggiunte alle richieste di origine](#add-origin-custom-headers-denylist)
+ [Configura CloudFront per inoltrare l'intestazione `Authorization`](#add-origin-custom-headers-forward-authorization)

## Casi d’uso
<a name="add-origin-custom-headers-use-cases"></a>

Puoi utilizzare intestazioni personalizzate, come riportato nei seguenti esempi:

**Identificazione delle richieste provenienti da CloudFront**  
Puoi identificare le richieste da cui proviene la tua origine CloudFront. Questo può essere utile se vuoi sapere se gli utenti stanno ignorando CloudFront la situazione o se utilizzi più di un CDN e desideri informazioni su quali richieste provengono da ogni CDN.  
Se utilizzi un'origine Amazon S3 e attivi la [registrazione degli accessi al server Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html), i log non includono le informazioni dell'intestazione.

**Determinare quali richieste provengono da una particolare distribuzione**  
Se configuri più di una CloudFront distribuzione per utilizzare la stessa origine, puoi aggiungere diverse intestazioni personalizzate in ciascuna distribuzione. È quindi possibile utilizzare i registri dell'origine per determinare quali richieste provengono da quale distribuzione CloudFront.

**Abilitazione della funzionalità Cross-Origin Resource Sharing (CORS)**  
Se alcuni dei tuoi visualizzatori non supportano la condivisione di risorse tra origini diverse (CORS), puoi configurare in modo CloudFront da aggiungere sempre l'`Origin`intestazione alle richieste inviate all'origine. Quindi puoi configurare la tua origine per restituire l'intestazione `Access-Control-Allow-Origin` per ogni richiesta. È inoltre necessario [configurare CloudFront per rispettare le impostazioni CORS](header-caching.md#header-caching-web-cors).

**Controllo dell'accesso ai contenuti**  
È possibile utilizzare intestazioni personalizzate per controllare l'accesso ai contenuti. Configurando l'origine in modo che risponda alle richieste solo quando includono un'intestazione personalizzata che viene aggiunta da CloudFront, impedisci agli utenti di ignorare CloudFront e accedere ai tuoi contenuti direttamente dall'origine. Per ulteriori informazioni, consulta [Limitazione dell’accesso ai file su origini personalizzate](private-content-overview.md#forward-custom-headers-restrict-access).

## Configura CloudFront per aggiungere intestazioni personalizzate alle richieste di origine
<a name="add-origin-custom-headers-configure"></a>

Per configurare una distribuzione in modo da aggiungere intestazioni personalizzate alle richieste inviate all'origine, aggiornare la configurazione di origine utilizzando uno dei seguenti metodi:
+ **CloudFront console**: quando crei o aggiorni una distribuzione, specifica i nomi e i valori delle intestazioni nelle impostazioni **Aggiungi intestazioni personalizzate**. Per ulteriori informazioni, consulta [Aggiunta di intestazioni personalizzate](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders).
+ **CloudFront API**: per ogni origine a cui desideri aggiungere intestazioni personalizzate, specifica i nomi e i valori delle intestazioni nel campo all'interno. `CustomHeaders` `Origin` Per ulteriori informazioni, consulta [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)o [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)consulta *Amazon CloudFront API Reference*.

Se i nomi e i valori delle intestazioni specificati non sono già presenti nella richiesta del visualizzatore, li CloudFront aggiunge alla richiesta di origine. Se è presente un'intestazione, CloudFront sovrascrive il valore dell'intestazione prima di inoltrare la richiesta all'origine.

Per le quote che si applicano alle intestazioni personalizzate di origine, consulta [Quote delle intestazioni](cloudfront-limits.md#limits-custom-headers).

## Intestazioni personalizzate che CloudFront non possono essere aggiunte alle richieste di origine
<a name="add-origin-custom-headers-denylist"></a>

Non puoi CloudFront configurare l'aggiunta delle seguenti intestazioni alle richieste inviate all'origine:
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ Intestazioni che iniziano con `X-Amz-`
+ Intestazioni che iniziano con `X-Edge-`
+ `X-Real-Ip`

## Configura CloudFront per inoltrare l'intestazione `Authorization`
<a name="add-origin-custom-headers-forward-authorization"></a>

Quando CloudFront inoltra una richiesta di visualizzazione all'origine, per impostazione predefinita CloudFront rimuove alcune intestazioni del visualizzatore, inclusa l'intestazione. `Authorization` Per assicurarti che l'origine riceva sempre l'intestazione `Authorization` nelle richieste di origine, sono disponibili le seguenti opzioni:
+ Aggiungere l'intestazione `Authorization` alla chiave cache utilizzando una policy di cache. Tutte le intestazioni nella chiave cache vengono incluse automaticamente nelle richieste di origine. Per ulteriori informazioni, consulta [Controllo della chiave della cache con una policy](controlling-the-cache-key.md).
+ Utilizzare una policy di richiesta di origine che inoltra tutte le intestazioni del visualizzatore all'origine. Non puoi inoltrare l'`Authorization`intestazione singolarmente in una policy di richiesta di origine, ma quando inoltri tutte le intestazioni del visualizzatore CloudFront include l'intestazione nelle richieste dei `Authorization` visualizzatori. CloudFront **fornisce una politica di richiesta di origine gestita per questo caso d'uso, denominata Managed-. AllViewer** Per ulteriori informazioni, consulta [Utilizzo delle policy di richiesta origine gestite](using-managed-origin-request-policies.md).

# Come CloudFront elabora le richieste parziali per un oggetto (intervallo GETs)
<a name="RangeGETs"></a>

Per un oggetto di grandi dimensioni, il visualizzatore (il browser web o un altro client) può eseguire più richieste `GET` e utilizzare l'intestazione della richiesta `Range` per scaricare l'oggetto in parti più piccole. Queste richieste per intervalli di byte, talvolta note come richieste `Range GET`, migliorano l'efficienza di download parziali e il ripristino da parte di trasferimenti in parte non riusciti. 

Quando CloudFront riceve una `Range GET` richiesta, controlla la cache nell'edge location che ha ricevuto la richiesta. Se la cache in quella edge location contiene già l'intero oggetto o la parte dell'oggetto richiesta, serve CloudFront immediatamente l'intervallo richiesto dalla cache.

Se la cache non contiene l'intervallo richiesto, CloudFront inoltra la richiesta all'origine. (Per ottimizzare le prestazioni, CloudFront può richiedere un intervallo più ampio di quello richiesto dal client in`Range GET`.) Cosa succede dopo varia a seconda che il server di origine supporti o meno le richieste `Range GET`:
+ **Se l'origine supporta `Range GET` le richieste**, restituisce l'intervallo richiesto. CloudFront serve l'intervallo richiesto e lo memorizza anche nella cache per richieste future. (Amazon S3) supporta le richieste `Range GET`, così come molti server HTTP.)
+ **Se l'origine non supporta `Range GET` le richieste**, restituisce l'intero oggetto. CloudFront serve la richiesta corrente inviando l'intero oggetto e memorizzandolo anche nella cache per richieste future. Dopo aver CloudFront memorizzato l'intero oggetto in una cache edge, risponde alle nuove `Range GET` richieste servendo l'intervallo richiesto.

In entrambi i casi, CloudFront inizia a servire l'intervallo o l'oggetto richiesto all'utente finale non appena il primo byte arriva dall'origine.

**Nota**  
Se il visualizzatore effettua una `Range GET` richiesta e l'origine CloudFront ritorna`Transfer-Encoding: chunked`, restituisce l'intero oggetto al visualizzatore anziché l'intervallo richiesto.

CloudFront segue generalmente le specifiche RFC per l'`Range`intestazione. Tuttavia, se le intestazioni `Range` non rispettano i seguenti requisiti, CloudFront restituirà il codice di stato `200` con l'oggetto completo invece del codice di stato `206` con gli intervalli specificati:
+ Gli intervalli devono essere elencati in ordine crescente. Ad esempio, `100-200,300-400` è valido, `300-400,100-200` non è valido.
+ Gli intervalli non devono sovrapporsi. Ad esempio, `100-200,150-250` non è valido.
+ Tutti le specifiche degli intervalli devono essere valide. Ad esempio, non puoi specificare un valore negativo come parte di un intervallo.

Per ulteriori informazioni su intestazione della richiesta `Range`, consulta [Richieste di intervallo](https://httpwg.org/specs/rfc7233.html#range.requests) in RFC 7233 oppure [Range](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) nei documenti Web MDN.

## Utilizzare richieste di intervallo per memorizzare nella cache oggetti di grandi dimensioni
<a name="cache-large-objects-with-range-requests"></a>

Quando la memorizzazione nella cache è abilitata, CloudFront non recupera o memorizza nella cache un oggetto di dimensioni superiori a 50 GB. Quando un'origine indica che l'oggetto è più grande di questa dimensione (nell'intestazione della `Content-Length` risposta), CloudFront chiude la connessione all'origine e restituisce un errore al visualizzatore. (Con la memorizzazione nella cache disattivata, CloudFront può recuperare un oggetto più grande di questa dimensione dall'origine e passarlo al visualizzatore. Tuttavia, CloudFront non memorizza l'oggetto nella cache.)

Tuttavia, con le richieste di intervallo, è possibile utilizzare CloudFront per memorizzare nella cache un oggetto che è più grande della dimensione [massima del file memorizzabile nella cache](cloudfront-limits.md#limits-web-distributions). 

**Example Esempio**  

1.  Considera un’origine con un oggetto da 100 GB. Con la memorizzazione nella cache abilitata, CloudFront non recupera o memorizza nella cache un oggetto così grande. Tuttavia, il visualizzatore può inviare più richieste di intervallo per recuperare l'oggetto in parti, con ciascuna parte inferiore a 50 GB.

1. Il visualizzatore può richiedere l’oggetto in parti da 20 GB inviando una richiesta con l’intestazione `Range: bytes=0-21474836480` per recuperare la prima parte, un’altra richiesta con l’intestazione `Range: bytes=21474836481-42949672960` per recuperare la parte successiva e così via. 

1. Quando il visualizzatore ha ricevuto tutte le parti, può combinarle per costruire l'oggetto originale da 100 GB. 

1. In questo caso, CloudFront memorizza nella cache ciascuna delle parti da 20 GB dell'oggetto e può rispondere alle richieste successive per la stessa parte dalla cache.

Per una richiesta di intervallo relativa a un oggetto compresso, la richiesta di intervallo di byte si basa sulla dimensione compressa e non sulla dimensione originale dell’oggetto. Per ulteriori informazioni su questi file di compressione, consulta [Distribuzione di file compressi](ServingCompressedFiles.md).

# In che modo CloudFront elabora i codici di stato HTTP 3xx dalla tua origine
<a name="http-3xx-status-codes"></a>

Quando CloudFront richiede un oggetto dal bucket Amazon S3 o dal server di origine personalizzato, l'origine a volte restituisce un codice di stato HTTP 3xx. Il messaggio generalmente indica di procedere in uno dei seguenti modi:
+ L'URL dell'oggetto è stato modificato (ad esempio, codici di stato 301, 302, 307 o 308)
+ L'oggetto non è cambiato dall'ultima volta che lo ha CloudFront richiesto (codice di stato 304)

CloudFront memorizza nella cache le risposte 3xx in base alle impostazioni della CloudFront distribuzione e alle intestazioni della risposta. CloudFront memorizza nella cache le risposte 307 e 308 solo quando includi l'`Cache-Control`intestazione nelle risposte dall'origine. Per ulteriori informazioni, consulta [Gestione della durata di permanenza dei contenuti nella cache (scadenza)](Expiration.md).

Se la tua origine restituisce un codice di stato del reindirizzamento (ad esempio 301 o 307), CloudFront non segue il reindirizzamento. CloudFront trasmette la risposta 301 o 307 allo spettatore, che può seguire il reindirizzamento inviando una nuova richiesta.

# In che modo CloudFront elabora i codici di stato HTTP 4xx e 5xx dalla tua origine
<a name="HTTPStatusCodes"></a>

Quando CloudFront richiede un oggetto dal bucket Amazon S3 o dal server di origine personalizzato, l'origine a volte restituisce un codice di stato HTTP 4xx o 5xx, che indica che si è verificato un errore. CloudFront il comportamento dipende da:
+ Se hai configurato le pagine di errore personalizzate.
+ Se hai configurato per quanto tempo desideri CloudFront memorizzare nella cache le risposte agli errori dalla tua origine (errore di memorizzazione nella cache, TTL minimo)
+ Il codice di stato
+ Per i codici di stato 5xx, indica se l'oggetto richiesto si trova attualmente nella cache edge CloudFront
+ Per alcuni codici di stato 4xx, se il server di origine restituisce un’intestazione `Cache-Control max-age` o `Cache-Control s-maxage`.

CloudFront memorizza sempre nella cache le risposte `GET` e `HEAD` le richieste. È inoltre possibile configurare CloudFront la memorizzazione nella cache delle risposte alle `OPTIONS` richieste. CloudFront non memorizza nella cache le risposte alle richieste che utilizzano gli altri metodi.

Se l'origine non risponde, la CloudFront richiesta all'origine scade, il che è considerato un errore HTTP 5xx dall'origine, anche se l'origine non ha risposto con quell'errore. In questo scenario, CloudFront continua a fornire contenuti memorizzati nella cache. Per ulteriori informazioni, consulta [Origine non disponibile](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable).

Se hai abilitato la registrazione, CloudFront scrive i risultati nei log indipendentemente dal codice di stato HTTP.

Per ulteriori informazioni sulle funzionalità e le opzioni relative al messaggio di errore restituito da CloudFront, consulta quanto segue:
+ Per informazioni sulle impostazioni per le pagine di errore personalizzate nella CloudFront console, consulta[Custom Error Pages and Error Caching (Pagine di errore personalizzate e caching errori)](DownloadDistValuesErrorPages.md). 
+ Per informazioni sugli errori relativi alla memorizzazione nella cache del TTL minimo nella CloudFront console, consulta. [Error Caching Minimum TTL (seconds) (TTL minimo caching errori) (secondi)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL)
+ Per un elenco dei codici di stato HTTP memorizzati nella CloudFront cache, consulta. [codici di stato HTTP 4xx e 5xx che vengono memorizzati nella cache CloudFront](#HTTPStatusCodes-cached-errors)

**Topics**
+ [In che modo CloudFront elabora gli errori quando sono state configurate pagine di errore personalizzate](#HTTPStatusCodes-custom-error-pages)
+ [Come CloudFront elabora gli errori se non hai configurato pagine di errore personalizzate](#HTTPStatusCodes-no-custom-error-pages)
+ [codici di stato HTTP 4xx e 5xx che vengono memorizzati nella cache CloudFront](#HTTPStatusCodes-cached-errors)

## In che modo CloudFront elabora gli errori quando sono state configurate pagine di errore personalizzate
<a name="HTTPStatusCodes-custom-error-pages"></a>

Se sono state configurate pagine di errore personalizzate, CloudFront il comportamento dipende dal fatto che l'oggetto richiesto si trovi nella cache edge.

### L'oggetto richiesto non è nella cache edge
<a name="HTTPStatusCodes-custom-error-pages-not-in-cache"></a>

CloudFront continua a cercare di ottenere l'oggetto richiesto dall'origine quando tutte le seguenti condizioni sono vere:
+ Un visualizzatore richiede un oggetto.
+ L'oggetto non è nella cache edge.
+ L'origine restituisce un codice di stato HTTP 4xx o 5xx e una delle condizioni seguenti è vera:
  + Il tuo server di origine restituisce un codice di stato HTTP 5xx anziché un codice di stato 304 (Non modificato) o una versione aggiornata dell'oggetto.
  + Il tuo server di origine restituisce un codice di stato HTTP 4xx che non è limitato da un'intestazione di controllo cache ed è incluso nell'elenco seguente di codici di stato: [codici di stato HTTP 4xx e 5xx che vengono memorizzati nella cache CloudFront](#HTTPStatusCodes-cached-errors).
  + Il server di origine restituisce un codice di stato HTTP 4xx con un’intestazione `Cache-Control max-age` o `Cache-Control s-maxage` e il codice di stato è incluso nel seguente elenco di codici di stato: Control [Codici di stato HTTP 4xx che vengono memorizzati CloudFront nella cache in base alle intestazioni `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).

**CloudFront fa quanto segue:**

1. Nell' CloudFront edge cache che ha ricevuto la richiesta del visualizzatore, CloudFront controlla la configurazione della distribuzione e ottiene il percorso della pagina di errore personalizzata che corrisponde al codice di stato restituito dall'origine. 

1. CloudFront trova il primo comportamento della cache nella distribuzione che presenta un modello di percorso che corrisponde al percorso della pagina di errore personalizzata.

1. L' CloudFront edge location invia una richiesta per la pagina di errore personalizzata all'origine specificata nel comportamento della cache.

1. L'origine restituisce la pagina di errore personalizzata alla edge location.

1. CloudFront restituisce la pagina di errore personalizzata al visualizzatore che ha effettuato la richiesta e inoltre memorizza nella cache la pagina di errore personalizzata per il massimo dei seguenti elementi: 
   + La quantità di tempo specificata dal TTL minimo di caching degli errori (10 secondi per impostazione predefinita)
   + La quantità di tempo specificata da un'intestazione `Cache-Control max-age` o `Cache-Control s-maxage` restituita dall'origine quando la prima richiesta ha generato l'errore

1. Trascorso il tempo di memorizzazione nella cache (determinato nel passaggio 5), CloudFront riprova a recuperare l'oggetto richiesto inoltrando un'altra richiesta all'origine. CloudFront continua a riprovare a intervalli specificati dal TTL minimo di memorizzazione nella cache degli errori. 

**Nota**  
Se hai configurato anche un comportamento di cache per la stessa pagina di errore personalizzata, CloudFront utilizza invece il comportamento della cache TTL. In questo caso, CloudFront eseguirà le seguenti operazioni per i passaggi 5 e 6:  
Dopo aver CloudFront restituito la pagina di errore personalizzata al visualizzatore che ha effettuato la richiesta, CloudFront verifica il comportamento della cache TTL (ad esempio, si imposta il TTL predefinito su 5 secondi). CloudFront quindi memorizza nella cache la pagina di errore personalizzata fino a quel massimo.
 CloudFront Trascorsi 5 secondi, recupera nuovamente la pagina di errore personalizzata dall'origine. CloudFront continuerà a riprovare a intervalli specificati dal comportamento della cache TTL.
Per ulteriori informazioni, consulta [Impostazioni TTL](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) del comportamento cache.

### L'oggetto richiesto è nella cache edge
<a name="HTTPStatusCodes-custom-error-pages-in-cache"></a>

CloudFront continua a servire l'oggetto che si trova attualmente nella cache edge quando tutte le seguenti condizioni sono vere:
+ Un visualizzatore richiede un oggetto.
+ L'oggetto è nella cache edge ma è scaduto.
+ Il tuo server di origine restituisce un codice di stato HTTP 5xx anziché un codice di stato 304 (Non modificato) o una versione aggiornata dell'oggetto.

**CloudFront fa quanto segue:**

1. Se la tua origine restituisce un codice di stato 5xx, CloudFront serve l'oggetto anche se è scaduto. Per tutta la durata della memorizzazione degli errori nella cache, il TTL minimo CloudFront continua a rispondere alle richieste degli utenti servendo l'oggetto dalla cache perimetrale. 

   Se la tua origine restituisce un codice di stato 4xx, CloudFront restituisce il codice di stato, non l'oggetto richiesto, al visualizzatore. 

1. Una volta trascorso il TTL minimo di memorizzazione dell'errore nella cache, CloudFront riprova a recuperare l'oggetto richiesto inoltrando un'altra richiesta all'origine. Tieni presente che se l'oggetto non viene richiesto frequentemente, CloudFront potresti eliminarlo dalla cache edge mentre il server di origine sta ancora restituendo 5xx risposte. Per informazioni sulla durata della permanenza degli oggetti nelle cache CloudFront edge, consulta. [Gestione della durata di permanenza dei contenuti nella cache (scadenza)](Expiration.md)

## Come CloudFront elabora gli errori se non hai configurato pagine di errore personalizzate
<a name="HTTPStatusCodes-no-custom-error-pages"></a>

Se non hai configurato pagine di errore personalizzate, CloudFront il comportamento dipende dal fatto che l'oggetto richiesto si trovi o meno nella cache edge.

**Topics**
+ [L'oggetto richiesto non è nella cache edge](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [L'oggetto richiesto è nella cache edge](#HTTPStatusCodes-no-custom-error-pages-in-cache)

### L'oggetto richiesto non è nella cache edge
<a name="HTTPStatusCodes-no-custom-error-pages-not-in-cache"></a>

CloudFront continua a cercare di ottenere l'oggetto richiesto dall'origine quando tutte le seguenti condizioni sono vere:
+ Un visualizzatore richiede un oggetto.
+ L'oggetto non è nella cache edge.
+ L'origine restituisce un codice di stato HTTP 4xx o 5xx e una delle condizioni seguenti è vera:
  + Il tuo server di origine restituisce un codice di stato HTTP 5xx anziché un codice di stato 304 (Non modificato) o una versione aggiornata dell'oggetto.
  + Il tuo server di origine restituisce un codice di stato HTTP 4xx che non è limitato da un'intestazione di controllo cache ed è incluso nell'elenco seguente di codici di stato: [codici di stato HTTP 4xx e 5xx che vengono memorizzati nella cache CloudFront](#HTTPStatusCodes-cached-errors)
  + Il server di origine restituisce un codice di stato HTTP 4xx con un’intestazione `Cache-Control max-age` o `Cache-Control s-maxage` e il codice di stato è incluso nel seguente elenco di codici di stato: Control [Codici di stato HTTP 4xx che vengono memorizzati CloudFront nella cache in base alle intestazioni `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).

CloudFront fa quanto segue:

1. CloudFront restituisce il codice di stato 4xx o 5xx al visualizzatore e memorizza anche nella cache edge il codice di stato che ha ricevuto la richiesta per il massimo dei seguenti elementi: 
   + La quantità di tempo specificata dal TTL minimo di caching degli errori (10 secondi per impostazione predefinita)
   + La quantità di tempo specificata da un'intestazione `Cache-Control max-age` o `Cache-Control s-maxage` restituita dall'origine quando la prima richiesta ha generato l'errore

1. Per la durata del TTL minimo di caching degli errori (determinato nella fase 1), CloudFront risponde alle richieste visualizzatore successive per lo stesso oggetto con il codice di stato 4xx o 5xx memorizzato nella cache. 

1. Trascorso il tempo di memorizzazione nella cache (determinato nel passaggio 1), CloudFront riprova a recuperare l'oggetto richiesto inoltrando un'altra richiesta all'origine. CloudFront continua a riprovare a intervalli specificati dal TTL minimo di memorizzazione nella cache degli errori. 

### L'oggetto richiesto è nella cache edge
<a name="HTTPStatusCodes-no-custom-error-pages-in-cache"></a>

CloudFront continua a servire l'oggetto che si trova attualmente nella cache edge quando tutte le seguenti condizioni sono vere:
+ Un visualizzatore richiede un oggetto.
+ L'oggetto è nella cache edge ma è scaduto. Ciò significa che l’oggetto è *obsoleto*.
+ Il tuo server di origine restituisce un codice di stato HTTP 5xx anziché un codice di stato 304 (Non modificato) o una versione aggiornata dell'oggetto.

CloudFront fa quanto segue:

1. Se la tua origine restituisce un codice di errore 5xx, CloudFront serve l'oggetto anche se è scaduto. Per la durata del TTL minimo di memorizzazione nella cache degli errori (10 secondi per impostazione predefinita), CloudFront continua a rispondere alle richieste degli utenti servendo l'oggetto dalla cache edge. 

   Se la tua origine restituisce un codice di stato 4xx, CloudFront restituisce il codice di stato, non l'oggetto richiesto, al visualizzatore. 

1. Una volta trascorso il TTL minimo di memorizzazione dell'errore nella cache, CloudFront riprova a recuperare l'oggetto richiesto inoltrando un'altra richiesta all'origine. Se l'oggetto non viene richiesto frequentemente, è CloudFront possibile eliminarlo dalla cache edge mentre il server di origine restituisce ancora 5xx risposte. Per ulteriori informazioni, consulta [Gestione della durata di permanenza dei contenuti nella cache (scadenza)](Expiration.md).

**Suggerimento**  
Se configuri la direttiva `stale-if-error` o `Stale-While-Revalidate`, puoi specificare per quanto tempo gli oggetti obsoleti sono disponibili nella cache edge. Ciò consente di continuare a offrire contenuti ai visualizzatori anche quando l’origine non è disponibile. Per informazioni, consulta [Fornire contenuti obsoleti (scaduti)](Expiration.md#stale-content). 
CloudFront servirà solo un oggetto obsoleto fino al valore TTL [massimo](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) specificato. Dopo questo periodo, l’oggetto non sarà più disponibile dalla cache edge.

## codici di stato HTTP 4xx e 5xx che vengono memorizzati nella cache CloudFront
<a name="HTTPStatusCodes-cached-errors"></a>

CloudFront memorizza nella cache i codici di stato HTTP 4xx e 5xx restituiti dall'origine, a seconda del codice di stato specifico restituito e del fatto che l'origine restituisca intestazioni specifiche nella risposta.

CloudFront memorizza nella cache i seguenti codici di stato HTTP 4xx e 5xx restituiti dall'origine. Se hai configurato una pagina di errore personalizzata per un codice di stato HTTP, CloudFront memorizza nella cache la pagina di errore personalizzata. 

**Nota**  
Se utilizzi la politica di cache [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) gestita, CloudFront non memorizzerà nella cache questi codici di stato o pagine di errore personalizzate.


|  |  | 
| --- |--- |
|  404  |  Non trovato  | 
|  414  |  URI della richiesta troppo grande  | 
|  500  |  Errore interno del server  | 
|  501  |  Non ancora disponibile  | 
|  502  |  Gateway non valido  | 
|  503  |  Servizio non disponibile  | 
|  504  |  Timeout gateway  | 

### Codici di stato HTTP 4xx che vengono memorizzati CloudFront nella cache in base alle intestazioni `Cache-Control`
<a name="HTTPStatusCodes-cached-errors-with-cache-control"></a>

CloudFront memorizza nella cache solo i seguenti codici di stato HTTP 4xx restituiti dall'origine solo se l'origine restituisce un'intestazione or. `Cache-Control max-age` `Cache-Control s-maxage` Se hai configurato una pagina di errore personalizzata per uno di questi codici di stato HTTP e la tua origine restituisce una delle intestazioni di controllo della cache, memorizza nella cache la pagina di errore personalizzata. CloudFront 


|  |  | 
| --- |--- |
|  400  |  Richiesta non valida  | 
|  403  |  Accesso negato  | 
|  405  |  Metodo non consentito  | 
|  412¹  |  Precondizione non riuscita  | 
|  415¹  |  Tipo di supporto non supportato  | 

¹ CloudFront non supporta la creazione di pagine di errore personalizzate per questi codici di stato HTTP.

# Generazione di risposte di errore personalizzate
<a name="GeneratingCustomErrorResponses"></a>

Se un oggetto tramite il quale stai servendo non CloudFront è disponibile per qualche motivo, il tuo server web in genere restituisce un codice di stato HTTP pertinente CloudFront per indicarlo. Ad esempio, se un visualizzatore richiede un URL non valido, il server Web restituisce un codice di stato HTTP 404 (Not Found) a CloudFront, quindi lo CloudFront restituisce al visualizzatore. Invece di utilizzare questa risposta di errore predefinita, è possibile crearne una personalizzata che CloudFront ritorni al visualizzatore.

Se configurate CloudFront per restituire una pagina di errore personalizzata per un codice di stato HTTP ma la pagina di errore personalizzata non è disponibile, CloudFront restituisce al visualizzatore il codice di stato CloudFront ricevuto dall'origine che contiene le pagine di errore personalizzate. Ad esempio, supponiamo che l'origine personalizzata restituisca un codice di stato 500 e che tu abbia configurato CloudFront per ottenere una pagina di errore personalizzata per un codice di stato 500 da un bucket Amazon S3. Tuttavia, qualcuno ha eliminato accidentalmente la pagina di errore personalizzata dal tuo bucket Amazon S3. CloudFront restituisce un codice di stato HTTP 404 (Not Found) al visualizzatore che ha richiesto l'oggetto.

Quando CloudFront restituisci una pagina di errore personalizzata a un visualizzatore, paghi i CloudFront costi standard per la pagina di errore personalizzata, non i costi per l'oggetto richiesto. Per ulteriori informazioni sugli CloudFront addebiti, consulta la pagina [ CloudFrontdei prezzi di Amazon](https://aws.amazon.com/cloudfront/pricing/).

**Topics**
+ [Configurazione del comportamento di risposta agli errori](custom-error-pages-procedure.md)
+ [Creazione di una pagina di errore personalizzata per codici di stato HTTP specifici](creating-custom-error-pages.md)
+ [Archiviazione degli oggetti e delle pagine di errore personalizzate in diverse sedi](custom-error-pages-different-locations.md)
+ [Modificare i codici di risposta restituiti da CloudFront](custom-error-pages-response-code.md)
+ [Controlla per quanto tempo CloudFront memorizza gli errori nella cache](custom-error-pages-expiration.md)

# Configurazione del comportamento di risposta agli errori
<a name="custom-error-pages-procedure"></a>

Sono disponibili diverse opzioni per gestire la CloudFront risposta in caso di errore. Per configurare risposte di errore personalizzate, puoi utilizzare la CloudFront console, l' CloudFront API o CloudFormation. Indipendentemente dal modo in cui decidi di aggiornare la configurazione, prendi in considerazione i seguenti suggerimenti e consigli:
+ Salva le tue pagine di errore personalizzate in una posizione accessibile a CloudFront. Ti consigliamo di memorizzarle in un bucket Amazon S3 e di [non conservarle nello stesso percorso del resto del tuo sito Web o del contenuto dell'applicazione](custom-error-pages-different-locations.md). Se memorizzi le pagine di errore personalizzate sulla stessa origine del sito Web o dell'applicazione e l'origine inizia a restituire errori 5xx, non CloudFront puoi ottenere le pagine di errore personalizzate perché il server di origine non è disponibile. Per ulteriori informazioni, consulta [Archiviazione degli oggetti e delle pagine di errore personalizzate in diverse sedi](custom-error-pages-different-locations.md).
+ Assicurati che CloudFront disponga dell'autorizzazione per ottenere le tue pagine di errore personalizzate. Se le pagine di errore personalizzate sono archiviate in Amazon S3, le pagine devono essere accessibili pubblicamente oppure è necessario configurare un [controllo di accesso all' CloudFront origine (OAC](private-content-restricting-access-to-s3.md)). Se le pagine di errore personalizzate sono memorizzate in un'origine personalizzata, le pagine devono essere accessibili pubblicamente.
+ (Facoltativo) Se lo desideri, configura l'origine per aggiungere una intestazione `Cache-Control` o `Expires` insieme alle pagine di errore personalizzate. Puoi anche utilizzare l'impostazione **Error Caching Minimum TTL** per controllare per quanto tempo vengono memorizzate nella CloudFront cache le pagine di errore personalizzate. Per ulteriori informazioni, consulta [Controlla per quanto tempo CloudFront memorizza gli errori nella cache](custom-error-pages-expiration.md).

## Configurazione delle risposte di errore personalizzate
<a name="custom-error-pages-console"></a>

Per configurare risposte di errore personalizzate nella CloudFront console, è necessario disporre di una distribuzione. CloudFront Nella console, le impostazioni di configurazione per le risposte personalizzate agli errori sono disponibili solo per le distribuzioni esistenti. Per informazioni su come creare una distribuzione, consulta [Inizia con una distribuzione CloudFront standard](GettingStarted.SimpleDistribution.md).

------
#### [ Console ]

**Per configurare le risposte personalizzate agli errori (console)**

1. Accedi Console di gestione AWS e apri la pagina **Distribuzioni** nella CloudFront console all'indirizzo[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).

1. Nell'elenco delle distribuzioni, scegli la distribuzione da aggiornare.

1. Seleziona la scheda **Pagine errori** , quindi **Crea risposta personalizzata all'errore**.

1. Immetti i valori applicabili. Per ulteriori informazioni, consulta [Custom Error Pages and Error Caching (Pagine di errore personalizzate e caching errori)](DownloadDistValuesErrorPages.md).

1. Dopo aver immesso i valori desiderati, seleziona **Crea**.

------
#### [ CloudFront API or CloudFormation ]

Per configurare risposte di errore personalizzate con l' CloudFront API oppure CloudFormation, usa il `CustomErrorResponse` tipo in una distribuzione. Per ulteriori informazioni, consulta gli argomenti seguenti:
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) nella *Guida per l'utente di AWS CloudFormation *
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)nell'*Amazon CloudFront API Reference*

------

# Creazione di una pagina di errore personalizzata per codici di stato HTTP specifici
<a name="creating-custom-error-pages"></a>

Se preferisci visualizzare un messaggio di errore personalizzato anziché quello predefinito, ad esempio una pagina che utilizza la stessa formattazione del resto del sito Web, puoi fare in modo che venga CloudFront restituito al visualizzatore un oggetto (come un file HTML) che contiene il tuo messaggio di errore personalizzato.

Per specificare il file che desideri restituire e gli errori per i quali il file deve essere restituito, aggiorni la distribuzione per specificare tali valori. CloudFront Per ulteriori informazioni, consulta [Configurazione del comportamento di risposta agli errori](custom-error-pages-procedure.md).

Di seguito è riportata una pagina di errore personalizzata di esempio:

![\[Schermata di un esempio di pagina AWS 404 personalizzata.\]](http://docs.aws.amazon.com/it_it/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)


Puoi specificare un oggetto differente per ciascun codice di stato HTTP supportato, oppure puoi utilizzare lo stesso oggetto per tutti i codici di stato supportati. Puoi decidere di specificare pagine di errore personalizzate per alcuni codici di stato e non per altri.

Gli oggetti tramite i quali stai servendo CloudFront possono non essere disponibili per diversi motivi. Tali opzioni rientrano in due categorie generali:
+ Gli *errori del client* indicano un problema con la richiesta. Ad esempio, l'oggetto con il nome specificato non è disponibile oppure l'utente non possiede le autorizzazioni necessarie per ottenere un oggetto nel bucket Amazon S3. Quando si verifica un errore del client, l'origine restituisce un codice di stato HTTP nell'intervallo 4xx a CloudFront.
+ Gli *errori del server* indicano un problema con il server di origine. Ad esempio, il server HTTP è occupato o non disponibile. Quando si verifica un errore del server, il server di origine restituisce un codice di stato HTTP nell'intervallo 5xx o CloudFront non riceve una risposta dal server di origine per un certo periodo di tempo e presuppone un codice di stato 504 (Gateway Timeout). CloudFront

I codici di stato HTTP per i quali è CloudFront possibile restituire una pagina di errore personalizzata includono i seguenti:
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Note**  
Se CloudFront rileva che la richiesta potrebbe non essere sicura, CloudFront restituisce un errore 400 (Bad Request) anziché una pagina di errore personalizzata.
Puoi creare una pagina di errore personalizzata per il codice di stato HTTP 416 (Requested Range Not Satisfiable) e modificare il codice di stato HTTP che CloudFront restituisce agli utenti quando l'origine restituisce un codice di stato 416 a. CloudFront Per ulteriori informazioni, consulta [Modificare i codici di risposta restituiti da CloudFront](custom-error-pages-response-code.md). Tuttavia, CloudFront non memorizza nella cache le risposte del codice di stato 416, quindi anche se specifichi un valore per **Error Caching Minimum TTL** per il codice di stato 416, non lo utilizza. CloudFront 
In alcuni casi, CloudFront non restituisce una pagina di errore personalizzata per il codice di stato HTTP 503 anche se si configura in tal senso. CloudFront Se il codice CloudFront di errore è `Capacity Exceeded` o`Limit Exceeded`, CloudFront restituisce un codice di stato 503 al visualizzatore senza utilizzare la pagina di errore personalizzata.
Se hai creato una pagina di errore personalizzata, CloudFront restituirà `Connection: close` o `Connection: keep-alive` per i seguenti codici di risposta:  
CloudFront restituzioni `Connection: close` per i codici di stato: 400, 405, 414, 416, 500, 501
CloudFront restituisce `Connection: keep-alive` i codici di stato: 403, 404, 502, 503, 504

Per una spiegazione dettagliata di come vengono CloudFront gestite le risposte di errore provenienti dall'origine, consulta. [In che modo CloudFront elabora i codici di stato HTTP 4xx e 5xx dalla tua origine](HTTPStatusCodes.md)

# Archiviazione degli oggetti e delle pagine di errore personalizzate in diverse sedi
<a name="custom-error-pages-different-locations"></a>

Se desideri archiviare gli oggetti e le pagine di errore personalizzate in posizioni differenti, la tua distribuzione deve includere un comportamento cache per il quale le seguenti condizioni sono vere:
+ Il valore di **Path Pattern (Modello di percorso)** corrisponde al percorso dei tuoi messaggi di errore personalizzati. Ad esempio, hai salvato pagine di errore personalizzate per errori 4xx in un bucket Amazon S3 in una directory denominata `/4xx-errors`. La tua distribuzione deve includere un comportamento cache per il quale il modello di percorso instrada le richieste per le pagine di errore personalizzate a quella posizione, ad esempi, `/4xx-errors/*`.
+ Il valore di **Origin (Origine)** specifica il valore di **Origin ID (ID origine)** per l'origine che contiene le tue pagine di errore personalizzate.

Per ulteriori informazioni, consulta [Cache Behavior Settings (Impostazioni del comportamento della cache)](DownloadDistValuesCacheBehavior.md).

# Modificare i codici di risposta restituiti da CloudFront
<a name="custom-error-pages-response-code"></a>

Puoi configurare CloudFront in modo da restituire al visualizzatore un codice di stato HTTP diverso da quello CloudFront ricevuto dall'origine. Ad esempio, se la tua origine restituisce un codice di stato 500 aCloudFront, potresti CloudFront voler restituire una pagina di errore personalizzata e un codice di stato 200 (OK) al visualizzatore. Esistono diversi motivi per cui potresti voler restituire CloudFront al visualizzatore un codice di stato diverso da quello a cui è stato restituito l'origineCloudFront:
+ Alcuni dispositivi Internet (ad esempio, alcuni firewall e proxy aziendali) intercettano i codici HTTP 4xx e 5xx e impediscono la restituzione della risposta al visualizzatore. In questo scenario, se si sostituisce `200`, la risposta non viene intercettata.
+ Se non ti interessa distinguere tra diversi errori del client o del server, puoi specificare `400` o `500` come valore CloudFront restituito per tutti i codici di stato 4xx o 5xx.
+ Potresti scegliere di restituire un codice di stato `200` (OK) e un sito Web statico, in modo che i tuoi clienti non sappiano che il sito Web è inaccessibile.

Se abiliti [i log CloudFront standard](AccessLogs.md) e configuri CloudFront per modificare il codice di stato HTTP nella risposta, il valore della `sc-status` colonna nei log contiene il codice di stato specificato. Tuttavia, il valore della colonna `x-edge-result-type` non ne è interessato. Contiene il tipo di risultato della risposta dall'origine. Ad esempio, supponete di configurare CloudFront la restituzione di un codice di stato `200` al visualizzatore quando l'origine restituisce `404` (Not Found) a. CloudFront Quando l'origine risponde a una richiesta con un codice di stato `404`, il valore nella colonna `sc-status` nel log sarà `200`, ma il valore nella colonna `x-edge-result-type` sarà `Error`.

È possibile CloudFront configurare la restituzione di uno dei seguenti codici di stato HTTP insieme a una pagina di errore personalizzata:
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504

# Controlla per quanto tempo CloudFront memorizza gli errori nella cache
<a name="custom-error-pages-expiration"></a>

CloudFront memorizza nella cache le risposte agli errori per una durata predefinita di 10 secondi. CloudFront invia quindi la richiesta successiva per l'oggetto all'origine per verificare se il problema che ha causato l'errore è stato risolto e l'oggetto richiesto è disponibile.

È possibile specificare la durata della memorizzazione nella cache degli errori, ovvero l'**Error Caching Minimum TTL, per ogni codice di stato 4xx e 5xx inserito nella cache**. CloudFront Per ulteriori informazioni, consulta [codici di stato HTTP 4xx e 5xx che vengono memorizzati nella cache CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors). Quando specifichi una durata, è importante prestare attenzione alle seguenti informazioni:
+ Se specifichi una durata di memorizzazione nella cache degli errori breve, inoltra più richieste all'origine rispetto a quando specifichi una durata più lunga. CloudFront Per gli errori 5xx, questo potrebbe aggravare il problema che ha causato inizialmente l'errore del server di origine.
+ Quando l'origine restituisce un errore per un oggetto, CloudFront risponde alle richieste relative all'oggetto con la risposta all'errore o con la pagina di errore personalizzata fino allo scadere del periodo di memorizzazione nella cache degli errori. Se specificate una lunga durata di memorizzazione nella cache degli errori, CloudFront potreste continuare a rispondere alle richieste con una risposta di errore o con la pagina di errore personalizzata per un lungo periodo dopo che l'oggetto sarà nuovamente disponibile.

**Nota**  
Puoi creare una pagina di errore personalizzata per il codice di stato HTTP 416 (Impossibile attenersi all'intervallo richiesto) e modificare il codice di stato HTTP che CloudFront restituisce ai visualizzatori quando il server di origine restituisce a CloudFront un codice di stato 416. Per ulteriori informazioni, consulta [Modificare i codici di risposta restituiti da CloudFront](custom-error-pages-response-code.md). Tuttavia, CloudFront non memorizza nella cache le risposte del codice di stato 416, quindi anche se si specifica un valore per **Error Caching Minimum TTL** per il codice di stato 416, non lo utilizza. CloudFront

Se desideri controllare per quanto tempo CloudFront memorizza nella cache gli errori per i singoli oggetti, puoi configurare il tuo server di origine per aggiungere l'intestazione applicabile alla risposta di errore per quell'oggetto.

**Se l'origine aggiunge una `Cache-Control: s-maxage` direttiva `Cache-Control: max-age` or o un'`Expires`intestazione, CloudFront memorizza nella cache le risposte di errore per il valore maggiore tra il valore nell'intestazione o il TTL minimo di Error Caching.**

**Nota**  
I valori `Cache-Control: max-age` e `Cache-Control: s-maxage` non possono essere maggiori del valore **Maximum TTL** (TTL massimo) impostato per il comportamento cache per il quale la pagina di errore viene recuperata.

Se l'origine aggiunge una `Cache-Control: private` direttiva `Cache-Control: no-store``Cache-Control: no-cache`, o per i codici di errore 404, 410, 414 o 501, CloudFront non memorizza nella cache la risposta all'errore. **Per tutti gli altri codici di errore, CloudFront ignora le `private` direttive `no-store``no-cache`, e e memorizza nella cache la risposta di errore per il valore di Error Caching Minimum TTL.**

**Se l'origine aggiunge altre `Cache-Control` direttive o non aggiunge intestazioni, memorizza nella cache le risposte di errore per il valore di Error CloudFront Caching Minimum TTL.**

Se il periodo di scadenza per un codice di stato 4xx o 5xx per un oggetto è più lungo rispetto a quello che desideri attendere, puoi invalidare il codice di errore memorizzato nella cache utilizzando l'URL dell'oggetto richiesto. Se il server di origine restituisce un messaggio di errore per più oggetti, devi invalidare ogni oggetto separatamente. Per ulteriori informazioni sull'invalidamento degli oggetti, consulta [Invalidare i file per rimuovere il contenuto](Invalidation.md).

Se hai abilitato la memorizzazione nella cache per un'origine di bucket S3 e configuri un errore di memorizzazione nella cache di almeno 0 secondi nella tua CloudFront distribuzione, vedrai comunque un errore di memorizzazione nella cache TTL minimo di 1 secondo per gli errori di origine S3. CloudFront lo fa per proteggere la tua origine dagli attacchi S. DDo Non si applica ad altri tipi di origini.