Comportamento di richieste e risposte per origini personalizzate

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

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

Per comprendere 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 all'origine personalizzata

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

Autenticazione

Se inoltri l'Authorizationintestazione all'origine, puoi quindi configurare il server di origine per richiedere l'autenticazione del 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.

È possibile 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 gli oggetti rimangono in una CloudFront cache prima di CloudFront inoltrare un'altra richiesta all'origine, puoi:

Per ulteriori informazioni, consulta Gestisci la durata della 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 di 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 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 che inoltra a ELB e se l'indirizzo IP del server CloudFront perimetrale è 192.0.2.199, la richiesta ricevuta dall' EC2 istanza contiene l'intestazione seguente:

X-Forwarded-For: 192.0.2.2,192.0.2.199

Autenticazione SSL lato client

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

Compressione

Per ulteriori informazioni, consulta Servire 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, 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:

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

È possibile configurare CloudFront l'inoltro dei cookie all'origine. Per ulteriori informazioni, consulta Contenuto della cache basato sui cookie.

Cross-Origin Resource Sharing (CORS)

Se desideri CloudFront rispettare le impostazioni di condivisione delle risorse tra origini diverse, configura CloudFront l'inoltro dell'Originintestazione all'origine. Per ulteriori informazioni, consulta Contenuto della cache in base alle intestazioni delle richieste.

Crittografia

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:

CloudFront inoltra le richieste HTTPS al server di origine utilizzando i protocolli SSLv3, TLSv1 .0, TLSv1 .1 e .2. TLSv1 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, usa CloudFront sempre .2. TLSv1

Per ulteriori informazioni sull'utilizzo di HTTPS con CloudFront, consulta. Usa HTTPS con CloudFront 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

Richieste GET che includono un corpo

Se una GET richiesta del visualizzatore 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 che supporta, 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 È 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.

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 Contenuto della cache in base alle intestazioni delle richieste.

Versione HTTP

CloudFront inoltra le richieste all'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, l'eventuale stringa di query e le intestazioni, è di 20.480 byte.

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

Se una richiesta o un URL supera questi valori massimi, CloudFront restituisce il codice di stato HTTP 413, Request Entity Too Large, al visualizzatore, quindi interrompe la connessione TCP con il visualizzatore.

Stapling OCSP

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

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) in questa sezione Riferimento alle impostazioni di distribuzione.

Protocolli

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

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.

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

Stringhe di query

Puoi configurare se CloudFront inoltrare i parametri della stringa di query alla tua origine. Per ulteriori informazioni, consulta Contenuto della cache in base ai parametri della stringa di query.

Timeout connessione origine e tentativi

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 Controlla i timeout e i 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 (solo origini personalizzate e VPC).

Richieste simultanee per lo stesso oggetto (compressione richieste)

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

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 o ai cookie o alle stringhe di query, CloudFront inoltra tutte le richieste con una chiave di cache univoca all'origine.

Se vuoi evitare che tutte le richieste vengano compresse, puoi utilizzare la policy di cache gestitaCachingDisabled, che impedisce anche la memorizzazione nella cache. Per ulteriori informazioni, consulta Usa politiche di cache gestite.

Se vuoi evitare che la richiesta venga compressa per oggetti specifici, puoi impostare il TTL minimo per il comportamento della cache su 0 e configurare l'origine per inviareCache-Control: private,Cache-Control: no-store, Cache-Control: no-cache o. Cache-Control: max-age=0 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 dall'utente per visualizzare i tuoi contenuti, ti consigliamo di configurare l'inoltro CloudFront di una o più delle seguenti intestazioni all'origine personalizzata:

In base al valore dell'User-Agentintestazione, 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. Contenuto della cache in base alle intestazioni delle richieste

Puoi 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 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-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 dalla tua origine personalizzata

Scopri come CloudFront elabora le risposte dalla tua origine personalizzata.

Risposte 100 Continue

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

Richieste annullate

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

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'Varyintestazione come descritto in. Intestazioni di risposta HTTP che CloudFront rimuovono o sostituiscono

Cookie

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 Contenuto della cache basato sui cookie.

Connessioni TCP interrotte

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-Lengthintestazione nella risposta:

Si consiglia di configurare il server HTTP per aggiungere un'Content-Lengthintestazione per impedire CloudFront la memorizzazione nella cache 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 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.

Origine non disponibile

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

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

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 non appena l'oggetto viene ricevuto dall'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 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.