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 traiter et transférer les demandes vers votre origine personnalisée

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

Authentification

Si vous transmettez l’en-tête Authorization à votre origine, vous pouvez ensuite configurer votre serveur d’origine pour demander une authentification du client pour les types de demandes suivants :

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

Pour de plus amples informations, veuillez consulter Configurer CloudFront pour transférer l'Authorizationen-tête.

Vous pouvez utiliser HTTP ou HTTPS pour transmettre les demandes à votre serveur d’origine. Pour de plus amples informations, veuillez consulter 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 en CloudFront cache avant de CloudFront transmettre une autre demande à votre origine, vous pouvez :

Pour plus d’informations, consultez Gestion de la durée de conservation de contenu dans le cache (expiration).

Adresses IP client

Si un utilisateur envoie une demande à CloudFront et n'inclut pas d'en-tête de X-Forwarded-For demande, CloudFront il obtient son adresse IP à partir de la connexion TCP, ajoute un X-Forwarded-For en-tête qui inclut l'adresse IP et transmet la demande à l'origine. Par exemple, si CloudFront extrait 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 l'adresse IP du spectateur à partir de 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 qu'elle transmet à 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

Client-side Authentification SSL

CloudFront prend en charge l'authentification TLS mutuelle (mTLS) où le client et le serveur s'authentifient mutuellement à l'aide de certificats. Une fois mTLS configuré, CloudFront vous pouvez valider les certificats clients lors de la prise de contact TLS et éventuellement exécuter des CloudFront fonctions pour implémenter une logique de validation personnalisée.

Pour les origines qui demandent des certificats côté client lorsque mTLS n'est pas configuré, la demande est suppriméeCloudFront .

Pour plus d'informations sur la configuration de mTLS, consultezAssocier une fonction CloudFront de connexion.

CloudFront ne prend pas en charge l'authentification des clients à l'aide de certificats SSL côté client. Si une origine demande un certificat côté client, la demande est CloudFront supprimée.

Compression

Pour de plus amples informations, veuillez consulter Diffusion de fichiers compressés.

Demandes conditionnelles

Lorsqu'il CloudFront reçoit une demande concernant un objet qui a expiré depuis un cache périphérique, il transmet la demande à l'origine soit pour obtenir la dernière version de l'objet, soit pour obtenir la confirmation de l'origine 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 qui est CloudFront transmise à l'origine, ajoutez CloudFront l'un des éléments suivants ou les deux :

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

Cookies

Vous pouvez configurer CloudFront pour transférer les cookies vers votre source. Pour de plus amples informations, veuillez consulter Mise en cache de contenu basée sur des cookies.

Cross-origin partage de ressources (CORS)

Si vous souhaitez CloudFront respecter les paramètres de partage des ressources entre origines, configurez CloudFront pour transférer l'Originen-tête vers votre origine. Pour de plus amples informations, veuillez consulter Mise en cache de contenu basée sur des en-têtes de demandes.

Chiffrement

Vous pouvez demander aux spectateurs d'utiliser le protocole HTTPS pour envoyer des demandes CloudFront à votre origine personnalisée CloudFront et de transmettre les demandes à votre origine personnalisée en utilisant le protocole utilisé par l'observateur. 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,TLSv1.2, et TLSv1.3 . Pour les origines personnalisées, vous pouvez choisir les protocoles SSL que vous CloudFront souhaitez utiliser pour communiquer avec votre origine :

Si l'origine est un compartiment Amazon S3, la valeur par défaut CloudFront sera TLSv1.3.

Pour plus d'informations sur l'utilisation du protocole HTTPS avec CloudFront, consultezUtilisez le protocole HTTPS avec CloudFront. Pour obtenir la liste des chiffrements qui prennent CloudFront en charge la communication HTTPS entre les spectateurs et CloudFront, et entre CloudFront et votre origine, consultez. 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 visualiseur.

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 spectateurs et les transmet à votre origine personnalisée :

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

En-têtes et CloudFront comportement des requêtes HTTP (origines personnalisées et 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 :

Pour plus d’informations sur la mise en cache selon des valeurs d’en-tête, consultez Mise en cache de contenu basée sur des en-têtes de demandes.

Version de HTTP

CloudFront transmet les demandes à votre origine personnalisée en utilisant HTTP/1.1.

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

La longueur maximale d'une demande, y compris le chemin, la chaîne de requête (le cas échéant) et les en-têtes, est de 32 768 octets.

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

Si une URL dépasse la longueur maximale, CloudFront renvoie le code d'état HTTP 414 (URI trop long) à l'utilisateur. Si une demande dépasse la longueur maximale parce que la taille de l'en-tête est dépassée, CloudFront renvoie le code d'état HTTP 494 au visualiseur. Dans les deux cas, met CloudFront 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 des certificats 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 d'OCSP Stapling est plus prononcée lorsque CloudFront reçoit de nombreuses requêtes HTTPS pour des objets dans le même domaine. Chaque serveur situé dans un emplacement CloudFront périphérique doit soumettre une demande de validation distincte. Lorsque CloudFront reçoit de nombreuses requêtes HTTPS pour le même domaine, chaque serveur dans l'emplacement périphérique reçoit rapidement une réponse de l'autorité de certification qu'il peut « agrafer » (staple) dans un paquet de l'établissement de la liaison SSL ; lorsque l'utilisateur a vérifié que le certificat est valide, 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, de sorte que la prochaine fois qu'il recevra une demande incluant le même nom de domaine, il recevra une réponse de validation de la part de l'autorité de certification.

Connexions persistantes

Lorsque 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 Keep-alive timeout (origines personnalisées et VPC uniquement) dans la section Référence de tous les paramètres de distribution.

Protocoles

CloudFront transmet les requêtes HTTP ou HTTPS au serveur d'origine en fonction des critères suivants :

Si vous spécifiez HTTP uniquement ou HTTPS uniquement, CloudFront transmet les demandes au serveur d'origine en utilisant le protocole spécifié, quel que soit le protocole utilisé dans la demande du visualiseur.

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

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, UpdateDistribution consultez le manuel Amazon CloudFront API Reference.

Chaînes de requête

Vous pouvez configurer si les paramètres CloudFront de chaîne de requête sont transférés à votre origine. Pour de plus amples informations, veuillez consulter Mise en cache de contenu basée 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 à l'origine est le nombre de secondes qui CloudFront s'écoulent lors de la tentative d'établissement d'une connexion avec l'origine.

Les tentatives de connexion à l'origine sont le nombre de CloudFront tentatives de connexion à l'origine.

Ensemble, ces paramètres déterminent la durée pendant CloudFront laquelle vous essayez de vous connecter à 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 à l'utilisateur. Par défaut, CloudFront attend 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 plus d’informations, consultez Contrôle des délais d’expiration et des tentatives de l’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 :

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

Pour plus d’informations, y compris sur la manière de configurer le délai de réponse de l’origine, consultez Délai de réponse.

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 l'objet 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, CloudFront une pause s'arrête 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 d'origine à toutes les demandes qu'il 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 un 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 requêtes 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 la mise en cache en fonction des en-têtes de demande, des cookies ou des chaînes de requête, CloudFront toutes les demandes avec une clé de cache unique sont transmises à votre origine.

Si vous souhaitez empêcher la fusion des demandes, vous pouvez utiliser la politique de cache gérée CachingDisabled, qui empêche également la mise en cache. Pour de plus amples informations, veuillez consulter Utilisation des politiques de cache gérées.

Si vous souhaitez empêcher la fusion des demandes pour certains objets, vous pouvez définir la durée de vie minimale pour le comportement du cache sur 0 et configurer l’origine de sorte à envoyer Cache-Control: private, Cache-Control: no-store, Cache-Control: no-cache, Cache-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.

En-tête User-Agent

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

En fonction de la valeur de l'User-Agenten-tête, CloudFront définit la valeur de ces en-têtes à true ou false avant de transmettre la demande à votre origine. Si un appareil entre dans plusieurs catégories, plusieurs valeurs peuvent être true. Par exemple, pour certaines tablettes, CloudFront peut définir CloudFront-Is-Mobile-Viewer et CloudFront-Is-Tablet-Viewer sur true. Pour plus d'informations sur la configuration CloudFront de la mise en cache en fonction des en-têtes de demande, consultezMise en cache de contenu basée sur des en-têtes de demandes.

Vous pouvez CloudFront configurer la mise 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 a 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 CloudFront pas la mise en cache des objets en fonction des valeurs de l'User-AgentUser-Agenten-tête, CloudFront ajoute 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 en contienne User-Agent ou non. 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.

100 Continuer les réponses

Votre origine ne peut pas envoyer plus d'une réponse 100-Continuer à CloudFront. Après la première réponse 100-Continue, CloudFront s'attend à une réponse HTTP 200 OK. Si votre origine envoie une autre réponse 100-Continue après la première, une erreur CloudFront sera renvoyée.

Mise en cache

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é, CloudFront ne CloudFront met pas l'objet en cache à 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 mais transmet chaque demande ultérieure concernant l'objet à 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 est Vary:* renvoyée dans la réponse et si la valeur du TTL minimum 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 plus d’informations, consultez Mise en cache de contenu basée sur des cookies.

Connexions TCP annulées

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

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 spectateur :

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 CloudFront utiliser la mise en cache d'un objet dont la taille est supérieure à cette taille en utilisant des requêtes de plage pour demander les objets par parties de 50 Go ou moins chacune. CloudFrontmet ces parties en cache car chacune d'elles fait 50 Go ou moins. 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 de plus amples informations, veuillez consulter 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 la période spécifiée dans la Cache-Control max-age directive est écoulée), CloudFront soit diffuse la version expirée de l'objet, soit 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 traiter 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. Une fois que vous avez configuré la redirection, c'est 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 à l'utilisateur. CloudFront ne suit pas la redirection.

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

En-tête Transfer-Encoding

CloudFront prend uniquement en charge la chunked valeur de l'Transfer-Encodingen-tête. Si votre origine est renvoyéeTransfer-Encoding: chunked, CloudFront renvoie l'objet au client au fur et à mesure qu'il est reçu à l'emplacement périphérique, et met l'objet en cache 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 plus d’informations, consultez Connexions TCP annulées.