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 per origini personalizzate

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

In che modo CloudFront elabora e inoltra le richieste alla tua origine personalizzata

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

Autenticazione

Per inoltrare l’intestazione Authorization all’origine, puoi configurare il server di origine per richiedere l’autenticazione client per i seguenti tipi di richieste:

Per OPTIONS le richieste, l'autenticazione del client può essere configurata solo se si utilizzano le seguenti CloudFront impostazioni:

Per ulteriori informazioni, consulta Configura CloudFront per inoltrare l'intestazione Authorization.

Puoi utilizzare HTTP o HTTPS per inoltrare le richieste al server di origine. Per ulteriori informazioni, consulta Usa HTTPS con CloudFront.

Durata del caching e TTL minimo

Per controllare per quanto tempo i tuoi oggetti rimangono in una CloudFront cache prima di CloudFront inoltrare un'altra richiesta all'origine, puoi:

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

Indirizzi IP client

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-Forintestazione 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 della X-Forwarded-For richiesta, CloudFront ottiene l'indirizzo IP del visualizzatore dalla connessione TCP, lo aggiunge alla fine dell'X-Forwarded-Forintestazione 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 la seguente intestazione 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 delle applicazioni Web, i proxy inversi, i sistemi di prevenzione delle intrusioni e l'API Gateway, aggiungono l'indirizzo IP del server CloudFront perimetrale che ha inoltrato la richiesta alla fine dell'intestazione. X-Forwarded-For Ad esempio, se è CloudFront inclusa X-Forwarded-For: 192.0.2.2 in una richiesta che inoltra a ELB e se l'indirizzo IP del server CloudFront perimetrale è 192.0.2.199, la richiesta ricevuta dall'istanza EC2 contiene la seguente intestazione:

X-Forwarded-For: 192.0.2.2,192.0.2.199

Client-side Autenticazione SSL

CloudFront supporta l'autenticazione reciproca TLS (MTLS) in cui sia il client che il server si autenticano reciprocamente tramite certificati. Con gli MTL configurati, CloudFront può 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 sul lato client quando MTLS non è configurato, elimina la richiesta. CloudFront

Per ulteriori informazioni sulla configurazione degli MTL, vedere. Associare una funzione di CloudFront connessione

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

Compression

Per ulteriori informazioni, consulta Distribuzione di file compressi.

Richieste condizionali

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, includeva un ETag valore, un LastModified valore o entrambi i valori nella risposta. Nella nuova richiesta che CloudFront inoltra all'origine, CloudFront aggiunge uno o entrambi i seguenti elementi:

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

Cookie

Puoi configurare CloudFront l'inoltro dei cookie alla tua origine. Per ulteriori informazioni, consulta Caching dei contenuti basati su cookie.

Cross-origin condivisione delle risorse (CORS)

Se desideri CloudFront rispettare le impostazioni di condivisione delle risorse tra origini, configura CloudFront l'inoltro dell'Originintestazione all'origine. Per ulteriori informazioni, consulta Caching dei contenuti in base alle intestazioni di richiesta.

Encryption (Crittografia)

Puoi richiedere agli spettatori di utilizzare HTTPS per inviare richieste CloudFront e CloudFront inoltrare richieste alla tua origine personalizzata utilizzando il protocollo utilizzato dal visualizzatore. Per ulteriori informazioni, vedi le seguenti impostazioni di distribuzione:

CloudFront inoltra le richieste HTTPS al server di origine utilizzando i protocolli SSLv3,, TLSv1.0, TLSv1.1 e. TLSv1.2 TLSv1.3 Per le origini personalizzate, puoi scegliere i protocolli SSL che desideri utilizzare CloudFront per comunicare con la tua origine:

Se l'origine è un bucket Amazon S3, per impostazione predefinita CloudFront sarà. TLSv1.3

Per ulteriori informazioni sull'utilizzo di HTTPS con CloudFront, consulta. Usa HTTPS con CloudFront Per un elenco dei cifrari che CloudFront supportano la comunicazione HTTPS tra gli utenti e tra e la tua origine CloudFront, CloudFront consulta. Protocolli e cifrari supportati tra visualizzatori e CloudFront

Richieste GET che includono un corpo

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

Metodi HTTP

Se configuri CloudFront per elaborare tutti i metodi HTTP supportati, CloudFront accetta le seguenti richieste dai visualizzatori e le inoltra alla tua origine personalizzata:

CloudFront memorizza sempre nella cache le risposte e le richieste. GET HEAD Puoi anche configurare CloudFront la 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.

Intestazioni e CloudFront comportamento delle richieste HTTP (origini personalizzate e Amazon S3)

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:

Per ulteriori informazioni sul caching in base ai valori di intestazione, consulta Caching dei contenuti in base alle intestazioni di richiesta.

Versione HTTP

CloudFront inoltra le richieste alla tua origine personalizzata utilizzando. HTTP/1.1

Lunghezza massima di una richiesta e lunghezza massima di un URL

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 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 Too Long) al visualizzatore. Se una richiesta supera la lunghezza massima perché viene superata la dimensione dell'intestazione, CloudFront restituisce il codice di stato HTTP 494 al visualizzatore. In entrambi i casi, CloudFront quindi interrompe la connessione TCP al visualizzatore.

Stapling OCSP

Quando un visualizzatore invia una richiesta HTTPS per un oggetto, CloudFront oppure deve confermare con l'autorità di certificazione (CA) che il certificato SSL per il dominio non è stato revocato. La pinzatura OCSP velocizza la convalida del certificato 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 anche una richiesta di convalida alla CA, quindi la volta successiva che riceve una richiesta che include lo stesso nome di dominio, riceve una risposta di convalida dalla CA.

Connessioni persistenti

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 Keep-alive timeout (solo origini personalizzate e VPC) in questa sezione Riferimento a tutte le impostazioni di distribuzione.

Protocolli

CloudFront inoltra le richieste HTTP o HTTPS al server di origine in base a quanto segue:

Se specifichi 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 specifichi 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.

Per informazioni su come aggiornare una distribuzione tramite la console, consulta CloudFront . Aggiornamento di una distribuzione Per informazioni su come aggiornare una distribuzione utilizzando l' CloudFront API, consulta Amazon CloudFront API Reference. UpdateDistribution

Stringhe di query

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.

Timeout connessione origine e tentativi

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

I tentativi di connessione all'origine sono il numero di CloudFront tentativi di connessione 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.

Timeout di risposta dell'origine

Il timeout di risposta origine, noto anche come timeout di lettura origine o timeout di richiesta origine, si applica a entrambi i valori seguenti:

CloudFront il comportamento dipende dal metodo HTTP della richiesta del visualizzatore:

Per ulteriori informazioni, incluso il modo in cui configurare il timeout di risposta origine, consulta Timeout di risposta.

Richieste simultanee per lo stesso oggetto (compressione richieste)

Quando una CloudFront edge location riceve una richiesta per un oggetto e l'oggetto non è 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 della richiesta originale a tutte le richieste ricevute mentre era in pausa. Questa operazione è chiamata compressione richieste. Nei CloudFront log, la prima richiesta è identificata come a Miss nel x-edge-result-type campo e le richieste compresse sono identificate come. Hit Per ulteriori informazioni sui CloudFront log, vedereCloudFront e registrazione delle funzioni edge.

CloudFront comprime solo le richieste che condividono una chiave di cache. 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, 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.

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.

User-Agent Intestazione

Se desideri CloudFront memorizzare nella cache diverse versioni dei tuoi oggetti in base al dispositivo utilizzato da un utente per visualizzare i tuoi contenuti, ti consigliamo di configurare CloudFront l'inoltro di una o più delle seguenti intestazioni all'origine personalizzata:

In base al valore dell'User-Agentintestazione, CloudFront imposta il valore di queste intestazioni all'inoltro della richiesta all'origine true o false prima. 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

È possibile CloudFront configurare la memorizzazione nella cache degli oggetti in base ai valori nell'User-Agentintestazione, ma non è consigliabile. L'User-Agentintestazione ha molti valori possibili e la memorizzazione nella cache basata su tali valori comporterebbe l'inoltro CloudFront di molte più richieste all'origine.

Se non CloudFront configuri la memorizzazione nella cache degli oggetti in base ai valori dell'User-Agentintestazione, CloudFront aggiunge un'User-Agentintestazione 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-Agentintestazione, CloudFront la rimuove.

In che modo CloudFront elabora le risposte provenienti dalla tua origine personalizzata

Scopri come CloudFront elabora le risposte provenienti dalla tua origine personalizzata.

100 Continua le risposte

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

Caching

Richieste annullate

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

Negoziazione di contenuto

Se l'origine ritorna Vary:* nella risposta e se il valore del TTL minimo per il comportamento della cache corrispondente è 0, memorizza l'oggetto nella CloudFront cache ma inoltra comunque ogni richiesta successiva dell'oggetto all'origine per confermare che la cache contiene l'ultima versione dell'oggetto. CloudFront non include alcuna intestazione condizionale, ad esempio o. If-None-Match If-Modified-Since Di conseguenza, l'origine restituisce l'oggetto a CloudFront in risposta a ogni richiesta.

Se l'origine ritorna Vary:* nella risposta e se il valore di Minimum TTL per il corrispondente comportamento della cache è un altro valore, CloudFront elabora l'Varyintestazione come descritto in. Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono

Cookie

Se abiliti i cookie per un comportamento di cache e se l'origine restituisce 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.

Connessioni TCP interrotte

Se la connessione TCP tra CloudFront e l'origine si interrompe mentre l'origine restituisce un oggetto a CloudFront, il CloudFront comportamento dipende dal fatto che l'origine includa o meno un'Content-Lengthintestazione nella risposta:

Ti consigliamo di configurare il server HTTP per aggiungere un'Content-Lengthintestazione per evitare la memorizzazione nella cache CloudFront di oggetti parziali.

Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono

CloudFront rimuove o aggiorna i seguenti campi di intestazione prima di inoltrare la risposta dall'origine al visualizzatore:

Dimensione massima del file memorizzabile nella cache

La dimensione massima di un corpo di risposta che CloudFront salva 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 più grande di questa dimensione utilizzando le richieste di intervallo per richiedere gli oggetti in parti ciascuna di 50 GB o inferiori. CloudFrontmemorizza queste parti nella cache perché ognuna di esse è pari o inferiore a 50 GB. 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.

Origine non disponibile

Se il server di origine non è disponibile e CloudFront riceve una richiesta per un oggetto presente nella cache edge ma che è scaduto (ad esempio, perché è trascorso il periodo di tempo specificato nella Cache-Control max-age direttiva), CloudFront visualizza la versione scaduta dell'oggetto o una pagina di errore personalizzata. Per ulteriori informazioni sul CloudFront comportamento quando hai configurato pagine di errore personalizzate, consulta. Come CloudFront elabora gli errori quando hai configurato pagine di errore personalizzate

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

Reindirizzamenti

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:

Transfer-Encoding Intestazione

CloudFront supporta solo il chunked valore dell'intestazione. Transfer-Encoding Se l'origine viene restituitaTransfer-Encoding: chunked, CloudFront restituisce l'oggetto al client quando l'oggetto viene ricevuto nella posizione periferica 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 restituitaTransfer-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.