Comportement des demandes et des réponses pour les origines personnalisées - Amazon CloudFront
Comment CloudFront traite et transmet les demandes à votre point d'origine personnaliséComment CloudFront traite les réponses provenant de votre origine personnalisée

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Comportement des demandes et des réponses pour les origines personnalisées

Pour comprendre comment CloudFront traite les demandes et les réponses lorsque vous utilisez des origines personnalisées, consultez les sections suivantes :

Comment CloudFront traite et transmet les demandes à votre point d'origine personnalisé

Découvrez comment CloudFront traite les demandes des visiteurs et les transmet à votre origine personnalisée.

Authentification

Si vous transférez l'Authorizationen-tête à votre origine, vous pouvez ensuite configurer votre serveur d'origine pour demander l'authentification du client pour les types de demandes suivants :

  • DELETE

  • GET

  • HEAD

  • PATCH

  • PUT

  • POST

Pour les OPTIONS demandes, l'authentification du client ne peut être configurée que si vous utilisez les CloudFront paramètres suivants :

  • CloudFront est configuré pour transmettre l'Authorizationen-tête à votre origine

  • CloudFront est configuré pour ne pas mettre en cache la réponse aux OPTIONS demandes

Pour plus d’informations, consultez Configurer CloudFront pour transférer l'Authorizationen-tête.

Vous pouvez utiliser le protocole HTTP ou HTTPS pour transférer les demandes vers votre serveur d'origine. Pour plus d’informations, consultez Utilisez le protocole HTTPS avec CloudFront.

Durée de conservation dans le cache et durée de vie minimale

Pour contrôler la durée pendant laquelle vos objets restent dans CloudFront le cache avant CloudFront de transmettre une autre demande à votre origine, vous pouvez :

  • Configurer votre origine pour ajouter un Cache-Control ou un champ d’en-tête Expires à chaque objet.

  • Spécifiez une valeur pour le TTL minimal dans les comportements CloudFront du cache.

  • Utiliser la valeur par défaut de 24 heures.

Pour de plus amples informations, veuillez consulter Gérer la durée pendant laquelle le contenu reste dans le cache (expiration).

Adresses IP client

Si un utilisateur envoie une demande sans CloudFront inclure d'en-tête de X-Forwarded-For demande, CloudFront obtient l'adresse IP du spectateur à partir de la connexion TCP, ajoute un X-Forwarded-For en-tête incluant l'adresse IP et transmet la demande à l'origine. Par exemple, s'il CloudFront obtient l'adresse IP 192.0.2.2 de la connexion TCP, il transmet l'en-tête suivant à l'origine :

X-Forwarded-For: 192.0.2.2

Si un utilisateur envoie une demande CloudFront et inclut un en-tête de X-Forwarded-For demande, CloudFront obtient son adresse IP via la connexion TCP, l'ajoute à la fin de l'X-Forwarded-Foren-tête et transmet la demande à l'origine. Par exemple, si la demande du spectateur inclut X-Forwarded-For: 192.0.2.4,192.0.2.3 et CloudFront obtient l'adresse IP 192.0.2.2 de la connexion TCP, elle transmet l'en-tête suivant à l'origine :

X-Forwarded-For: 192.0.2.4,192.0.2.3,192.0.2.2

Certaines applications, telles que les équilibreurs de charge (y compris Elastic Load Balancing), les pare-feux d'applications Web, les proxys inverses, les systèmes de prévention des intrusions et API Gateway, ajoutent l'adresse IP du serveur CloudFront périphérique qui a transmis la demande à la fin de l'en-tête. X-Forwarded-For Par exemple, si elle est CloudFront incluse X-Forwarded-For: 192.0.2.2 dans une demande transmise à ELB et si l'adresse IP du serveur CloudFront Edge est 192.0.2.199, la demande que reçoit votre instance EC2 contient l'en-tête suivant :

X-Forwarded-For: 192.0.2.2,192.0.2.199

Note

L’en-tête X-Forwarded-For contient les adresses IPv4 (par exemple, 192.0.2.44) et les adresses IPv6 (par exemple, 2001:0db8:85a3::8a2e:0370:7334).

Notez également que l'X-Forwarded-Foren-tête peut être modifié par chaque nœud sur le chemin d'accès au serveur actuel (CloudFront). Pour plus d’informations, consultez la section 8.1 de la RFC 7239. Vous pouvez également modifier l'en-tête à l'aide des fonctions de calcul de CloudFront pointe.

Authentification SSL côté client

CloudFront ne prend pas en charge l'authentification client avec des certificats SSL côté client. Si une origine demande un certificat côté client, elle CloudFront supprime la demande.

Compression

Pour plus d’informations, consultez Servir des fichiers compressés.

Demandes conditionnelles

Lorsqu'il CloudFront reçoit une demande pour un objet qui a expiré depuis un cache périphérique, il la transmet à l'origine soit pour obtenir la dernière version de l'objet, soit pour obtenir de l'origine la confirmation que le cache CloudFront périphérique possède déjà la dernière version. Généralement, lorsque l'origine a envoyé l'objet pour la dernière fois CloudFront, elle a inclus une ETag valeur, une LastModified valeur ou les deux valeurs dans la réponse. Dans la nouvelle demande transmise CloudFront à l'origine, ajoutez l' CloudFront un des éléments suivants ou les deux :

  • Un en-tête If-Match ou If-None-Match qui contient la valeur ETag pour la version expirée de l’objet.

  • Un en-tête If-Modified-Since qui contient la valeur LastModified pour la version expirée de l’objet.

L'origine utilise ces informations pour déterminer si l'objet a été mis à jour et, par conséquent, s'il convient de renvoyer l'objet entier CloudFront ou de renvoyer uniquement un code d'état HTTP 304 (non modifié).

Note

If-Modified-Sinceet les demandes If-None-Match conditionnelles ne sont pas prises en charge lorsqu'elle CloudFront est configurée pour transférer les cookies (tous ou un sous-ensemble).

Pour plus d’informations, consultez Contenu du cache basé sur les cookies.

Cookies

Vous pouvez configurer CloudFront pour transférer les cookies à votre origine. Pour plus d’informations, consultez Contenu du cache basé sur les cookies.

Partage des ressources cross-origin (CORS)

Si vous souhaitez CloudFront respecter les paramètres de partage de ressources entre origines, configurez CloudFront pour transférer l'Originen-tête vers votre origine. Pour plus d’informations, consultez Contenu du cache basé sur les en-têtes des demandes.

Chiffrement

Vous pouvez demander aux utilisateurs d'utiliser le protocole HTTPS pour envoyer des demandes CloudFront et de CloudFront transférer les demandes à votre origine personnalisée en utilisant le protocole utilisé par le lecteur. Pour plus d’informations, consultez les paramètres de distribution suivants :

CloudFront transmet les requêtes HTTPS au serveur d'origine à l'aide des protocoles SSLv3, TLSv1.0, TLSv1.1 et TLSv1.2. Pour les origines personnalisées, vous pouvez choisir les protocoles SSL que vous CloudFront souhaitez utiliser pour communiquer avec votre origine :

  • Si vous utilisez la CloudFront console, choisissez les protocoles en cochant les cases Protocoles SSL d'origine. Pour plus d’informations, consultez Créer une distribution.

  • Si vous utilisez l' CloudFront API, spécifiez les protocoles à l'aide de l'OriginSslProtocolsélément. Pour plus d'informations, consultez OriginSslProtocolset consultez DistributionConfigle Amazon CloudFront API Reference.

Si l'origine est un compartiment Amazon S3, utilise CloudFront toujours TLSv1.2.

Important

Les autres versions de SSL et TLS ne sont pas prises en charge.

Pour plus d'informations sur l'utilisation du protocole HTTPS avec CloudFront, consultezUtilisez le protocole HTTPS avec CloudFront. Pour obtenir la liste des chiffrements compatibles CloudFront avec les communications HTTPS entre les utilisateurs et CloudFront, et entre CloudFront et votre origine, voir. Protocoles et chiffrements pris en charge entre les utilisateurs et CloudFront

Demandes GET qui incluent un corps de texte

Si une GET demande d'utilisateur inclut un corps, CloudFront renvoie un code d'état HTTP 403 (Interdit) au lecteur.

Méthodes HTTP

Si vous configurez CloudFront pour traiter toutes les méthodes HTTP qu'il prend en charge, CloudFront accepte les demandes suivantes des utilisateurs et les transmet à votre origine personnalisée :

  • DELETE

  • GET

  • HEAD

  • OPTIONS

  • PATCH

  • POST

  • PUT

CloudFront met toujours en cache les réponses GET et les HEAD demandes. Vous pouvez également configurer CloudFront pour mettre en cache les réponses aux OPTIONS demandes. CloudFront ne met pas en cache les réponses aux demandes qui utilisent les autres méthodes.

Pour plus d’informations sur la façon de configurer si votre origine personnalisée traite ces méthodes, consultez la documentation de votre origine.

Important

Si vous configurez CloudFront pour accepter et transmettre à votre origine toutes les méthodes HTTP compatibles, configurez votre serveur d'origine pour qu' CloudFront il gère toutes les méthodes. Par exemple, si vous configurez CloudFront pour accepter et transférer ces méthodes parce que vous souhaitez les utiliserPOST, vous devez configurer votre serveur d'origine pour qu'il gère les DELETE demandes de manière appropriée afin que les utilisateurs ne puissent pas supprimer les ressources que vous ne souhaitez pas qu'ils suppriment. Pour plus d’informations, consultez la documentation de votre serveur HTTP.

En-têtes et CloudFront comportement des requêtes HTTP (personnalisés et origines d'Amazon S3)

Le tableau suivant répertorie les en-têtes de requête HTTP que vous pouvez transmettre aux origines Amazon S3 et personnalisée (avec les exceptions qui sont notées). Pour chaque en-tête, le tableau comprend des informations sur les points suivants :

  • CloudFront comportement si vous ne configurez pas CloudFront pour transférer l'en-tête vers votre origine, ce qui entraîne la mise en cache CloudFront de vos objets en fonction des valeurs de l'en-tête.

  • Si vous pouvez configurer CloudFront pour mettre en cache des objets en fonction des valeurs d'en-tête de cet en-tête.

    Vous pouvez configurer CloudFront pour mettre en cache des objets en fonction des valeurs User-Agent des en-têtes Date et, mais nous ne le recommandons pas. Ces en-têtes ont de nombreuses valeurs possibles, et la mise en cache basée sur leurs valeurs entraînerait le transfert d'un plus grand nombre de demandes CloudFront vers votre origine.

Pour plus d’informations sur la mise en cache selon des valeurs d’en-tête, consultez Contenu du cache basé sur les en-têtes des demandes.

En-tête Comportement si vous ne configurez pas CloudFront le cache en fonction des valeurs d'en-tête La mise en cache en fonction de valeurs d’en-tête est prise en charge

En-têtes définis par un tiers

Paramètres de cache existants : CloudFront transmet les en-têtes à votre source.

Oui

Accept

CloudFront supprime l'en-tête.

Oui

Accept-Charset

CloudFront supprime l'en-tête.

Oui

Accept-Encoding

Si la valeur contient gzip oubr, CloudFront transmet un Accept-Encoding en-tête normalisé à votre origine.

Pour plus d’informations, consultez Prise en charge de la compression et Servir des fichiers compressés.

Oui

Accept-Language

CloudFront supprime l'en-tête.

Oui

Authorization

  • GETet HEAD demandes : CloudFront supprime le champ Authorization d'en-tête avant de transférer la demande à votre origine.

  • OPTIONSdemandes — CloudFront supprime le champ Authorization d'en-tête avant de transférer la demande à votre origine si vous configurez CloudFront pour mettre en cache les réponses aux OPTIONS demandes.

    CloudFront transmet le champ Authorization d'en-tête à votre origine si vous ne configurez pas CloudFront pour mettre en cache les réponses aux requêtes OPTIONS.

  • DELETE, PATCHPOST, et PUT demandes : CloudFront ne supprime pas le champ d'en-tête avant de transférer la demande à votre origine.

Oui

Cache-Control

CloudFront transmet l'en-tête à votre origine.

Non

CloudFront-Forwarded-Proto

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d’informations, consultez Configurer la mise en cache en fonction du protocole de la demande.

Oui

CloudFront-Is-Desktop-Viewer

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d’informations, consultez Configuration de la mise en cache en fonction du type d'appareil.

Oui

CloudFront-Is-Mobile-Viewer

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d’informations, consultez Configuration de la mise en cache en fonction du type d'appareil.

Oui

CloudFront-Is-Tablet-Viewer

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Pour plus d’informations, consultez Configuration de la mise en cache en fonction du type d'appareil.

Oui

CloudFront-Viewer-Country

CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine.

Oui

Connection

CloudFront remplace cet en-tête par Connection: Keep-Alive avant de transmettre la demande à votre origine.

Non

Content-Length

CloudFront transmet l'en-tête à votre origine.

Non

Content-MD5

CloudFront transmet l'en-tête à votre origine.

Oui

Content-Type

CloudFront transmet l'en-tête à votre origine.

Oui

Cookie

Si vous configurez CloudFront pour transférer les cookies, le champ d'Cookieen-tête sera redirigé vers votre origine. Si ce n'est pas le cas, CloudFront supprime le champ Cookie d'en-tête. Pour plus d’informations, consultez Contenu du cache basé sur les cookies.

Non

Date

CloudFront transmet l'en-tête à votre origine.

Oui, mais non recommandé

Expect

CloudFront supprime l'en-tête.

Oui

From

CloudFront transmet l'en-tête à votre origine.

Oui

Host

CloudFront définit la valeur du nom de domaine de l'origine associé à l'objet demandé.

Vous ne pouvez pas mettre en cache en fonction de l'en-tête Host pour Amazon S3 ou MediaStore Origins.

Oui (personnalisée)

Non (S3 et MediaStore)

If-Match

CloudFront transmet l'en-tête à votre origine.

Oui

If-Modified-Since

CloudFront transmet l'en-tête à votre origine.

Oui

If-None-Match

CloudFront transmet l'en-tête à votre origine.

Oui

If-Range

CloudFront transmet l'en-tête à votre origine.

Oui

If-Unmodified-Since

CloudFront transmet l'en-tête à votre origine.

Oui

Max-Forwards

CloudFront transmet l'en-tête à votre origine.

Non

Origin

CloudFront transmet l'en-tête à votre origine.

Oui

Pragma

CloudFront transmet l'en-tête à votre origine.

Non

Proxy-Authenticate

CloudFront supprime l'en-tête.

Non

Proxy-Authorization

CloudFront supprime l'en-tête.

Non

Proxy-Connection

CloudFront supprime l'en-tête.

Non

Range

CloudFront transmet l'en-tête à votre origine. Pour plus d’informations, consultez Comment CloudFront traite les demandes partielles pour un objet (plage GETS).

Oui, par défaut

Referer

CloudFront supprime l'en-tête.

Oui

Request-Range

CloudFront transmet l'en-tête à votre origine.

Non

TE

CloudFront supprime l'en-tête.

Non

Trailer

CloudFront supprime l'en-tête.

Non

Transfer-Encoding

CloudFront transmet l'en-tête à votre origine.

Non

Upgrade

CloudFront supprime l'en-tête, sauf si vous avez établi une WebSocket connexion.

Non (sauf pour les WebSocket connexions)

User-Agent

CloudFront remplace la valeur de ce champ d'en-tête parAmazon CloudFront. Si vous souhaitez CloudFront mettre en cache votre contenu en fonction de l'appareil utilisé par l'utilisateur, consultezConfiguration de la mise en cache en fonction du type d'appareil.

Oui, mais non recommandé

Via

CloudFront transmet l'en-tête à votre origine.

Oui

Warning

CloudFront transmet l'en-tête à votre origine.

Oui

X-Amz-Cf-Id

CloudFront ajoute l'en-tête à la demande du lecteur avant de la transmettre à votre source. La valeur d’en-tête contient une chaîne chiffrée qui identifie de façon unique la demande.

Non

X-Edge-*

CloudFront supprime tous les X-Edge-* en-têtes.

Non

X-Forwarded-For

CloudFront transmet l'en-tête à votre origine. Pour plus d’informations, consultez Adresses IP client.

Oui

X-Forwarded-Proto

CloudFront supprime l'en-tête.

Non

X-HTTP-Method-Override

CloudFront supprime l'en-tête.

Oui

X-Real-IP

CloudFront supprime l'en-tête.

Non

Version de HTTP

CloudFront transmet les demandes à votre origine personnalisée à l'aide du protocole HTTP/1.1.

Longueur maximale d’une demande et longueur maximale d’une URL

La longueur maximale d’une demande, avec le chemin, la chaîne de requête (le cas échéant) et les en-têtes inclus, est de 20480 octets.

CloudFront construit une URL à partir de la requête. La longueur maximale de cette URL est de 8 192 caractères.

Si une demande ou une URL dépasse ces valeurs maximales, CloudFront renvoie le code d'état HTTP 413, Request Entity Too Large, au visualiseur, puis met fin à la connexion TCP avec le visualiseur.

OCSP Stapling

Lorsqu'un utilisateur soumet une demande HTTPS pour un objet, l'un CloudFront ou l'autre doit confirmer auprès de l'autorité de certification (CA) que le certificat SSL du domaine n'a pas été révoqué. L'agrafage OCSP accélère la validation du certificat en permettant de valider le certificat et de CloudFront mettre en cache la réponse de l'autorité de certification, de sorte que le client n'a pas besoin de valider le certificat directement auprès de l'autorité de certification.

L'amélioration des performances de l'agrafage OCSP est plus prononcée lors de la CloudFront réception de nombreuses requêtes HTTPS pour des objets du même domaine. Chaque serveur situé dans un emplacement CloudFront périphérique doit soumettre une demande de validation distincte. Lorsqu'il CloudFront reçoit un grand nombre de requêtes HTTPS pour le même domaine, chaque serveur situé à la périphérie reçoit rapidement une réponse de l'autorité de certification lui indiquant qu'il peut « agrafer » un paquet dans le cadre de la poignée de contact SSL ; lorsque le téléspectateur est convaincu que le certificat est valide, il CloudFront peut servir l'objet demandé. Si votre distribution ne reçoit pas beaucoup de trafic dans un emplacement CloudFront périphérique, les nouvelles demandes sont plus susceptibles d'être dirigées vers un serveur qui n'a pas encore validé le certificat auprès de l'autorité de certification. Dans ce cas, le visualiseur exécute séparément l'étape de validation et le CloudFront serveur sert l'objet. Ce CloudFront serveur soumet également une demande de validation à l'autorité de certification. Ainsi, la prochaine fois qu'il recevra une demande contenant le même nom de domaine, il recevra une réponse de validation de la part de l'autorité de certification.

Connexions persistantes

Lorsqu'il CloudFront reçoit une réponse de votre origine, il essaie de maintenir la connexion pendant plusieurs secondes au cas où une autre demande arriverait pendant cette période. Maintenir une connexion persistante permet de gagner le temps requis pour ré-établir la connexion TCP et établir une autre liaison TLS pour les demandes ultérieures.

Pour plus d’informations, y compris sur la manière de configurer la durée des connexions persistantes, consultez Délai d'attente des connexions actives (origines personnalisées uniquement) dans la section Référence des paramètres de distribution.

Protocoles

CloudFront transmet les requêtes HTTP ou HTTPS au serveur d'origine en fonction des éléments suivants :

  • Protocole de la demande à laquelle le spectateur envoie CloudFront, HTTP ou HTTPS.

  • La valeur du champ Origin Protocol Policy dans la CloudFront console ou, si vous utilisez l' CloudFront API, l'OriginProtocolPolicyélément du type DistributionConfig complexe. Dans la CloudFront console, les options sont HTTP uniquement, HTTPS uniquement et Match Viewer.

Si vous spécifiez HTTP uniquement ou HTTPS uniquement, CloudFront transfère les demandes au serveur d'origine en utilisant le protocole spécifié, quel que soit le protocole indiqué dans la demande du lecteur.

Si vous spécifiez Match Viewer, CloudFront transmet les demandes au serveur d'origine en utilisant le protocole indiqué dans la demande du visualiseur. Notez que l'objet n'est mis en CloudFront cache qu'une seule fois, même si les utilisateurs font des demandes à l'aide des protocoles HTTP et HTTPS.

Important

Si une CloudFront demande est transmise à l'origine à l'aide du protocole HTTPS, et si le serveur d'origine renvoie un certificat non valide ou un certificat auto-signé, CloudFront la connexion TCP est interrompue.

Pour plus d'informations sur la mise à jour d'une distribution à l'aide de la CloudFront console, consultezMettre à jour une distribution. Pour plus d'informations sur la mise à jour d'une distribution à l'aide de l' CloudFront API, UpdateDistributionconsultez le Amazon CloudFront API Reference.

Chaînes de requête

Vous pouvez configurer si les paramètres CloudFront de la chaîne de requête sont transmis à votre origine. Pour plus d’informations, consultez Contenu du cache basé sur les paramètres de chaîne de requête.

Délai d’attente et tentatives de connexion à l’origine

Le délai d'expiration de la connexion d'origine est le nombre de secondes d' CloudFront attente lorsque vous essayez d'établir une connexion avec l'origine.

Les tentatives de connexion à l'origine correspondent au nombre de CloudFront tentatives de connexion à l'origine.

Ensemble, ces paramètres déterminent la durée des CloudFront tentatives de connexion à l'origine avant de basculer vers l'origine secondaire (dans le cas d'un groupe d'origine) ou de renvoyer une réponse d'erreur au lecteur. Par défaut, CloudFront attend jusqu'à 30 secondes (3 tentatives de 10 secondes chacune) avant de tenter de se connecter à l'origine secondaire ou de renvoyer une réponse d'erreur. Vous pouvez réduire ce délai en spécifiant moins de tentatives, un délai d’attente de connexion plus court, ou les deux.

Pour de plus amples informations, veuillez consulter Contrôlez les délais et les tentatives d'origine.

Délai de réponse de l’origine

Le délai de réponse de l’origine, également appelé délai d’attente des opérations de lecture depuis l’origine ou délai de demande à l’origine, s’applique aux deux valeurs suivantes :

  • Durée, en secondes, d' CloudFront attente d'une réponse après le transfert d'une demande à l'origine.

  • Temps d' CloudFront attente, en secondes, après réception d'un paquet de réponse provenant de l'origine et avant de recevoir le paquet suivant.

CloudFront le comportement dépend de la méthode HTTP de la requête du spectateur :

  • GETet HEAD demandes : si l'origine ne répond pas ou cesse de répondre dans le délai imparti, interrompt CloudFront la connexion. Si le nombre spécifié de tentatives de connexion d'origine est supérieur à 1, CloudFront réessaie pour obtenir une réponse complète. CloudFront essaie jusqu'à 3 fois, selon la valeur du paramètre des tentatives de connexion d'origine. Si l'origine ne répond pas lors de la dernière tentative, elle CloudFront ne réessaie pas tant qu'elle n'a pas reçu une autre demande de contenu sur la même origine.

  • DELETE,OPTIONS, PATCHPUT, et POST demandes : si l'origine ne répond pas dans les 30 secondes, CloudFront interrompt la connexion et n'essaie pas de la contacter à nouveau. Le client peut soumettre à nouveau la demande si nécessaire.

Pour de plus amples informations, y compris sur la manière de configurer le délai de réponse de l’origine, veuillez consulter Délai de réponse (origines personnalisées uniquement).

Demandes simultanées pour le même objet (réduction des demandes)

Lorsqu'un emplacement CloudFront périphérique reçoit une demande pour un objet et que celui-ci n'est pas dans le cache ou que l'objet mis en cache a expiré, envoie CloudFront immédiatement la demande à l'origine. Toutefois, s'il existe des demandes simultanées pour le même objet, c'est-à-dire si des demandes supplémentaires pour le même objet (avec la même clé de cache) arrivent à l'emplacement périphérique avant de CloudFront recevoir la réponse à la première demande, faites CloudFront une pause avant de transmettre les demandes supplémentaires à l'origine. Cette brève pause permet de réduire la charge sur l'origine. CloudFront envoie la réponse de la demande initiale à toutes les demandes qu'elle a reçues pendant sa pause. Ce processus se nomme la réduction des demandes. Dans CloudFront les journaux, la première demande est identifiée comme étant Miss dans le x-edge-result-type champ, et les demandes réduites sont identifiées comme unHit. Pour plus d'informations sur CloudFront les journaux, consultezCloudFront et journalisation des fonctions Edge.

CloudFront réduit uniquement les demandes qui partagent une clé de cache. Si les demandes supplémentaires ne partagent pas la même clé de cache parce que, par exemple, vous avez configuré CloudFront le cache en fonction des en-têtes de demande, des cookies ou des chaînes de requête, CloudFront transfère toutes les demandes avec une clé de cache unique à votre origine.

Si vous souhaitez empêcher le regroupement de toutes les demandes, vous pouvez utiliser la politique de cache géréCachingDisabled, qui empêche également la mise en cache. Pour plus d’informations, consultez Utiliser des politiques de cache gérées.

Si vous souhaitez empêcher la réduction des demandes pour des objets spécifiques, vous pouvez définir le TTL minimum pour le comportement du cache sur 0 et configurer l'origine à envoyerCache-Control: private,, Cache-Control: no-store Cache-Control: no-cacheCache-Control: max-age=0, ou. Cache-Control: s-maxage=0 Ces configurations augmenteront la charge sur votre origine et introduiront une latence supplémentaire pour les demandes simultanées qui sont suspendues pendant l' CloudFront attente de la réponse à la première demande.

Important

Actuellement, la réduction des demandes CloudFront n'est pas prise en charge si vous activez le transfert de cookies dans la politique de cache, la politique de demande d'origine ou les anciens paramètres de cache.

En-tête User-Agent

Si vous souhaitez CloudFront mettre en cache différentes versions de vos objets en fonction de l'appareil utilisé par l'utilisateur pour consulter votre contenu, nous vous recommandons de configurer CloudFront pour transférer un ou plusieurs des en-têtes suivants vers votre origine personnalisée :

  • CloudFront-Is-Desktop-Viewer

  • CloudFront-Is-Mobile-Viewer

  • CloudFront-Is-SmartTV-Viewer

  • CloudFront-Is-Tablet-Viewer

Sur la base de la valeur de l'User-Agenten-tête, CloudFront définit la valeur de ces en-têtes false avant true ou avant le transfert de la demande à votre origine. Si un appareil entre dans plusieurs catégories, plusieurs valeurs peuvent être true. Par exemple, pour certaines tablettes, CloudFront vous pouvez définir les deux options CloudFront-Is-Mobile-Viewer et la valeur CloudFront-Is-Tablet-Viewer surtrue. Pour plus d'informations sur la configuration CloudFront de la mise en cache en fonction des en-têtes de demande, consultezContenu du cache basé sur les en-têtes des demandes.

Vous pouvez configurer CloudFront pour mettre en cache des objets en fonction des valeurs de l'User-Agenten-tête, mais nous ne le recommandons pas. L'User-Agenten-tête comporte de nombreuses valeurs possibles, et la mise en cache basée sur ces valeurs entraînerait le transfert CloudFront d'un plus grand nombre de demandes vers votre origine.

Si vous ne configurez pas CloudFront pour mettre en cache les objets en fonction des valeurs de l'User-Agent CloudFront User-Agenten-tête, ajoutez un en-tête avec la valeur suivante avant de transmettre une demande à votre origine :

User-Agent = Amazon CloudFront

CloudFront ajoute cet en-tête, que la demande du visualiseur contienne ou non un User-Agent en-tête. Si la demande du visualiseur inclut un User-Agent en-tête, CloudFront supprimez-le.

Comment CloudFront traite les réponses provenant de votre origine personnalisée

Découvrez comment CloudFront traite les réponses provenant de votre origine personnalisée.

Réponses 100 Continue

Votre origine ne peut pas envoyer plus d'une réponse de type 100-Continue à CloudFront. Après la première réponse 100-Continue, CloudFront attend une réponse HTTP 200 OK. Si votre origine envoie une autre réponse 100-Continue après la première, elle CloudFront renverra un message d'erreur.

Mise en cache

  • Assurez-vous que le serveur d’origine définit des valeurs valides et précises pour les champs d’en-tête Date et Last-Modified.

  • CloudFront respecte normalement un Cache-Control: no-cache en-tête dans la réponse depuis l'origine. Pour une exception, consultez Demandes simultanées pour le même objet (réduction des demandes).

Requêtes annulées

Si un objet ne se trouve pas dans le cache périphérique et si un utilisateur met fin à une session (par exemple, ferme un navigateur) après avoir récupéré l'objet depuis votre origine mais avant de pouvoir livrer l'objet demandé, il CloudFront ne CloudFront met pas l'objet en cache dans l'emplacement périphérique.

Négociation de contenu

Si votre origine est renvoyée Vary:* dans la réponse, et si la valeur du TTL minimum pour le comportement de cache correspondant est 0, CloudFront met l'objet en cache tout en transmettant toutes les demandes suivantes à l'origine pour confirmer que le cache contient la dernière version de l'objet. CloudFront n'inclut aucun en-tête conditionnel, tel que If-None-Match ouIf-Modified-Since. Par conséquent, votre origine renvoie l'objet à CloudFront en réponse à chaque demande.

Si votre origine renvoie Vary:* la réponse, et si la valeur de Minimum TTL pour le comportement de cache correspondant est une autre valeur, CloudFront traite l'Varyen-tête comme décrit dansEn-têtes de réponse HTTP qui CloudFront suppriment ou remplacent.

Cookies

Si vous activez les cookies pour un comportement de cache, et si l'origine renvoie des cookies avec un objet, met en CloudFront cache à la fois l'objet et les cookies. Notez que cela réduit la capacité de mise en cache pour un objet. Pour de plus amples informations, veuillez consulter Contenu du cache basé sur les cookies.

Connexions TCP annulées

Si la connexion TCP entre votre origine CloudFront et votre origine est interrompue alors que votre origine renvoie un objet CloudFront, le CloudFront comportement dépend du fait que votre origine a inclus ou non un Content-Length en-tête dans la réponse :

  • En-tête Content-Length : CloudFront renvoie l'objet au visualiseur au fur et à mesure qu'il l'obtient depuis votre origine. Toutefois, si la valeur de l'Content-Lengthen-tête ne correspond pas à la taille de l'objet, l'objet CloudFront n'est pas mis en cache.

  • Encodage de transfert : découpé : CloudFront renvoie l'objet au visualiseur au fur et à mesure qu'il l'obtient depuis votre origine. Toutefois, si la réponse segmentée n'est pas complète, l'objet CloudFront n'est pas mis en cache.

  • Aucun en-tête Content-Length : CloudFront renvoie l'objet au visualiseur et le met en cache, mais l'objet n'est peut-être pas complet. Sans Content-Length en-tête, CloudFront impossible de déterminer si la connexion TCP a été interrompue accidentellement ou intentionnellement.

Nous vous recommandons de configurer votre serveur HTTP pour ajouter un Content-Length en-tête afin d' CloudFront empêcher la mise en cache d'objets partiels.

En-têtes de réponse HTTP qui CloudFront suppriment ou remplacent

CloudFront supprime ou met à jour les champs d'en-tête suivants avant de transmettre la réponse de votre origine au lecteur :

  • Set-Cookie— Si vous configurez CloudFront pour transférer les cookies, le champ Set-Cookie d'en-tête sera transmis aux clients. Pour plus d’informations, consultez Contenu du cache basé sur les cookies.

  • Trailer

  • Transfer-Encoding— Si votre origine renvoie ce champ d'en-tête CloudFront , définissez la valeur sur chunked avant de renvoyer la réponse au spectateur.

  • Upgrade

  • Vary – Notez ce qui suit :

    • Si vous configurez CloudFront pour transférer l'un des en-têtes spécifiques à l'appareil vers votre origine (CloudFront-Is-Desktop-Viewer,, CloudFront-Is-Mobile-ViewerCloudFront-Is-SmartTV-Viewer,CloudFront-Is-Tablet-Viewer) et que vous configurez votre origine pour qu'elle revienne Vary:User-Agent à CloudFront, CloudFront revient Vary:User-Agent au visualiseur. Pour plus d’informations, consultez Configuration de la mise en cache en fonction du type d'appareil.

    • Si vous configurez votre origine pour inclure l'un Accept-Encoding ou l'autre Cookie dans l'Varyen-tête, CloudFront inclut les valeurs dans la réponse au visualiseur.

    • Si vous configurez CloudFront pour transférer les en-têtes vers votre origine, et si vous configurez votre origine pour renvoyer les noms des en-têtes CloudFront dans l'Varyen-tête (par exemple,Vary:Accept-Charset,Accept-Language), CloudFront renvoie l'Varyen-tête avec ces valeurs au visualiseur.

    • Pour plus d'informations sur CloudFront le traitement d'une valeur de * dans l'Varyen-tête, consultezNégociation de contenu.

    • Si vous configurez votre origine pour inclure d'autres valeurs dans l'Varyen-tête, CloudFront supprimez les valeurs avant de renvoyer la réponse au visualiseur.

  • Via— CloudFront définit la valeur suivante dans la réponse au visualiseur :

    Via: version_http chaîne_alphanumérique.cloudfront.net (CloudFront)

    Par exemple, la valeur est similaire à la suivante :

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

Taille de fichier maximale pouvant être mise en cache

La taille maximale d'un corps de réponse enregistré CloudFront dans son cache est de 50 Go. Cette taille inclut les réponses de transfert fragmentées qui ne spécifient pas la valeur d’en-tête Content-Length.

Vous pouvez utiliser CloudFront pour mettre en cache un objet dont la taille est supérieure à cette taille en utilisant des demandes de plage pour demander les objets dans des parties dont la taille est inférieure ou égale à 50 Go. CloudFrontmet en cache ces parties car chacune d'elles a une taille inférieure ou égale à 50 Go. Une fois que l’utilisateur a récupéré toutes les parties de l’objet, il peut reconstruire l’objet d’origine plus large. Pour plus d’informations, consultez Utiliser les demandes de plage pour mettre en cache de large objets.

Origine non disponible

Si votre serveur d'origine n'est pas disponible et CloudFront reçoit une demande pour un objet qui se trouve dans le cache périphérique mais qui a expiré (par exemple, parce que le délai spécifié dans la Cache-Control max-age directive est dépassé), CloudFront il diffuse la version expirée de l'objet ou affiche une page d'erreur personnalisée. Pour plus d'informations sur CloudFront le comportement lorsque vous avez configuré des pages d'erreur personnalisées, consultezComment CloudFront traite les erreurs lorsque vous avez configuré des pages d'erreur personnalisées.

Dans certains cas, un objet rarement demandé est expulsé et n'est plus disponible dans le cache périphérique. CloudFront ne peut pas servir un objet qui a été expulsé.

Redirections

Si vous changez l’emplacement d’un objet sur le serveur d’origine, vous pouvez configurer votre serveur Web afin de rediriger les demandes vers le nouvel emplacement. Après avoir configuré la redirection, la première fois qu'un utilisateur soumet une demande pour l'objet, CloudFront envoie la demande à l'origine, qui répond par une redirection (par exemple,302 Moved Temporarily). CloudFront met en cache la redirection et la renvoie au visualiseur. CloudFront ne suit pas la redirection.

Vous pouvez configurer votre serveur Web afin de rediriger les demandes vers l’un des emplacements suivants :

  • La nouvelle URL de l’objet sur le serveur d’origine. Lorsque le lecteur suit la redirection vers la nouvelle URL, il contourne l'URL d'origine CloudFront et se dirige directement vers l'URL d'origine. Par conséquent, nous vous recommandons de ne pas rediriger les demandes vers la nouvelle URL de l'objet sur l'origine.

  • La nouvelle CloudFront URL de l'objet. Lorsque le lecteur soumet la demande contenant la nouvelle CloudFront URL, CloudFront récupère l'objet depuis le nouvel emplacement de votre origine, le met en cache à l'emplacement périphérique et renvoie l'objet au visualiseur. Les demandes suivantes pour l’objet seront servies par l’emplacement périphérique. Ceci évite la latence et la charge associées aux utilisateurs qui demandent l’objet à l’origine. Cependant, chaque nouvelle demande pour l'objet entraînera des frais pour deux demandes adressées àCloudFront.

En-tête Transfer-Encoding

CloudFront ne prend en charge que la chunked valeur de l'Transfer-Encodingen-tête. Si votre origine revientTransfer-Encoding: chunked, CloudFront renvoie l'objet au client dès qu'il est reçu à l'emplacement périphérique et met en cache l'objet au format fragmenté pour les demandes suivantes.

Si le visualiseur fait une Range GET demande et que l'origine revientTransfer-Encoding: chunked, CloudFront renvoie l'objet entier au visualiseur au lieu de la plage demandée.

Nous vous recommandons d’utiliser un encodage fragmenté si la longueur du contenu de votre réponse ne peut pas être prédéterminé. Pour de plus amples informations, veuillez consulter Connexions TCP annulées.