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
Les rubriques suivantes décrivent le mode de CloudFront gestion des demandes et des réponses.
Découvrez comment CloudFront interagit avec Amazon S3 ou des origines personnalisées, gère les différentes méthodes et en-têtes HTTP, traite les codes d'état et gère la mise en cache et les réponses aux erreurs.
**Topics**
+ [Comment CloudFront traite les requêtes HTTP et HTTPS](HTTPandHTTPSRequests.md)
+ [Comportement des demandes et des réponses pour les origines Amazon S3 Origins](RequestAndResponseBehaviorS3Origin.md)
+ [Comportement des demandes et des réponses pour les origines personnalisées](RequestAndResponseBehaviorCustomOrigin.md)
+ [Comportement des requêtes et des réponses pour les groupes d’origine](RequestAndResponseBehaviorOriginGroups.md)
+ [Ajout d’en-têtes personnalisés aux demandes d’origine](add-origin-custom-headers.md)
+ [Comment CloudFront traite les demandes partielles pour un objet (plage GETs)](RangeGETs.md)
+ [Comment CloudFront traite les codes d'état HTTP 3xx de votre origine](http-3xx-status-codes.md)
+ [Comment CloudFront traite les codes d'état HTTP 4xx et 5xx de votre origine](HTTPStatusCodes.md)
+ [Génération de réponses aux·erreurs personnalisées](GeneratingCustomErrorResponses.md)
# Comment CloudFront traite les requêtes HTTP et HTTPS
Pour les origines d'Amazon S3, CloudFront accepte par défaut les requêtes via les protocoles HTTP et HTTPS pour les objets d'une CloudFront distribution. CloudFront transmet ensuite les demandes à votre compartiment Amazon S3 en utilisant le même protocole que celui dans lequel les demandes ont été effectuées.
Pour les origines personnalisées, lorsque vous créez une distribution, vous pouvez spécifier la manière dont CloudFront accède à votre origine : HTTP uniquement ou en adoptant le protocole utilisé par l'utilisateur. Pour plus d'informations sur le CloudFront traitement des requêtes HTTP et HTTPS pour des origines personnalisées, consultez[Protocoles](RequestAndResponseBehaviorCustomOrigin.md#RequestCustomProtocols).
Pour plus d’informations sur la façon de restreindre votre distribution pour que les utilisateurs finaux puissent uniquement accéder aux objets à l’aide de HTTPS, consultez [Utilisez le protocole HTTPS avec CloudFront](using-https.md).
**Note**
Les frais pour les requêtes HTTPS sont plus élevés que ceux pour les requêtes HTTP. Pour plus d'informations sur les taux de facturation, consultez la section [CloudFront tarification](https://aws.amazon.com/cloudfront/#pricing).
# Comportement des demandes et des réponses pour les origines Amazon S3 Origins
Pour comprendre comment CloudFront traite les demandes et les réponses lorsque vous utilisez Amazon S3 comme origine, consultez les sections suivantes :
**Topics**
+ [Comment CloudFront traite et transmet les demandes à votre Amazon S3 d'origine](#RequestBehaviorS3Origin)
+ [Comment CloudFront traite les réponses provenant de votre Amazon S3](#ResponseBehaviorS3Origin)
## Comment CloudFront traite et transmet les demandes à votre Amazon S3 d'origine
Découvrez comment CloudFront traite les demandes des visiteurs et les transmet à votre point d'origine Amazon S3.
**Contents**
+ [Durée de conservation dans le cache et durée de vie minimale](#RequestS3Caching)
+ [Adresses IP client](#RequestS3IPAddresses)
+ [Demandes GET conditionnelles](#RequestS3ConditionalGETs)
+ [Cookies](#RequestS3Cookies)
+ [Partage des ressources cross-origin (CORS)](#RequestS3-cors)
+ [Demandes GET qui incluent un corps de texte](#RequestS3-get-body)
+ [Méthodes HTTP](#RequestS3HTTPMethods)
+ [En-têtes de requête HTTP qui CloudFront suppriment ou mettent à jour](#request-s3-removed-headers)
+ [Longueur maximale d’une demande et longueur maximale d’une URL](#RequestS3MaxRequestStringLength)
+ [OCSP Stapling](#request-s3-ocsp-stapling)
+ [Protocoles](#RequestS3Protocol)
+ [Chaînes de requête](#RequestS3QueryStrings)
+ [Délai d’attente et tentatives de connexion à l’origine](#s3-origin-timeout-attempts)
+ [Délai de réponse de l’origine](#RequestS3RequestTimeout)
+ [Demandes simultanées pour le même objet (réduction des demandes)](#request-s3-traffic-spikes)
### 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 plus d’informations, consultez [Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md).
### Adresses IP client
Si un utilisateur envoie une demande CloudFront et n'inclut pas 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 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-For`en-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`
**Note**
L'`X-Forwarded-For`en-tête contient des IPv4 adresses (telles que 192.0.2.44) et des IPv6 adresses (telles que 2001:0 db 8:85 a3 : :8a2e : 0370:7334).
### Demandes GET conditionnelles
Lorsqu'il CloudFront reçoit une demande concernant un objet expiré depuis un cache périphérique, il la transmet à l'origine Amazon S3 pour obtenir la dernière version de l'objet ou pour obtenir la confirmation d'Amazon S3 que le cache CloudFront périphérique possède déjà la dernière version. Lorsque Amazon S3 a initialement envoyé l'objet à CloudFront, il a inclus une `ETag` valeur et une `LastModified` valeur dans la réponse. Dans la nouvelle demande transmise CloudFront à Amazon S3, CloudFront ajoute l'un des en-têtes 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.
Amazon S3 utilise ces informations pour déterminer si l'objet a été mis à jour et, par conséquent, s'il convient de renvoyer l'objet dans son intégralité CloudFront ou de renvoyer uniquement un code d'état HTTP 304 (non modifié).
### Cookies
Amazon S3 ne traite pas les cookies. Si vous configurez un comportement de cache pour transférer des cookies vers une origine Amazon S3, CloudFront transférez les cookies, mais Amazon S3 les ignore. Toutes les demandes futures pour le même objet, que vous faites varier le cookie ou non, sont servies à partir de l’objet existant dans le cache.
### Partage des ressources cross-origin (CORS)
Si vous CloudFront souhaitez respecter les paramètres de partage de ressources entre origines d'Amazon S3, configurez CloudFront pour transférer les en-têtes sélectionnés vers Amazon S3. Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des en-têtes de demandes](header-caching.md).
### 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 point d'origine Amazon S3 :
+ `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 utilisant les autres méthodes.
Si vous souhaitez utiliser des téléchargements en plusieurs parties pour ajouter des objets à un compartiment Amazon S3, vous devez ajouter un contrôle CloudFront d'accès à l'origine (OAC) à votre distribution et donner à l'OAC les autorisations nécessaires. Pour de plus amples informations, veuillez consulter [Restriction de l’accès à une origine Amazon S3](private-content-restricting-access-to-s3.md).
**Important**
Si vous configurez CloudFront pour accepter et transférer vers Amazon S3 toutes les méthodes HTTP prises CloudFront en charge, vous devez créer un CloudFront OAC pour restreindre l'accès à votre contenu Amazon S3 et donner à l'OAC les autorisations requises. Par exemple, si vous configurez CloudFront pour accepter et transférer ces méthodes parce que vous souhaitez les utiliser, vous devez configurer les `PUT` politiques relatives aux compartiments Amazon S3 afin de traiter les `DELETE` demandes de manière appropriée afin que les utilisateurs ne puissent pas supprimer les ressources que vous ne souhaitez pas voir supprimées. Pour de plus amples informations, veuillez consulter [Restriction de l’accès à une origine Amazon S3](private-content-restricting-access-to-s3.md).
Pour plus d’informations sur les opérations prises en charge par Amazon S3, consultez la [documentation Amazon S3](https://docs.aws.amazon.com/s3/index.html).
### En-têtes de requête HTTP qui CloudFront suppriment ou mettent à jour
CloudFront supprime ou met à jour certains en-têtes avant de transférer les demandes à votre origine Amazon S3. Pour la plupart des en-têtes, ce comportement est le même que pour les origines personnalisées. Pour obtenir la liste complète des en-têtes de requête HTTP et leur mode CloudFront de traitement, consultez[En-têtes et CloudFront comportement des requêtes HTTP (personnalisés et origines d'Amazon S3)](RequestAndResponseBehaviorCustomOrigin.md#request-custom-headers-behavior).
### 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 requête. 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) au visualiseur. 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, CloudFront il 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 lorsque vous recevez de CloudFront nombreuses requêtes HTTPS pour des objets du même domaine. Chaque serveur d'un emplacement périphérique CloudFront 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 qu'il peut agrafer sur un paquet dans le cadre de la poignée de main 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 périphérique CloudFront , il est plus probable que les nouvelles demandes soient acheminé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.
### Protocoles
CloudFront transmet les requêtes HTTP ou HTTPS au serveur d'origine en fonction du protocole de la demande du visualiseur, HTTP ou HTTPS.
**Important**
Si votre compartiment Amazon S3 est configuré comme point de terminaison de site Web, vous ne pouvez pas le configurer CloudFront pour utiliser le protocole HTTPS pour communiquer avec votre origine, car Amazon S3 ne prend pas en charge les connexions HTTPS dans cette configuration.
### Chaînes de requête
Vous pouvez configurer si CloudFront les paramètres de chaîne de requête sont transmis à votre origine Amazon S3. Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur les paramètres de chaîne de requête](QueryStringParameters.md).
### 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 plus d’informations, consultez [Contrôle des délais d’expiration et des tentatives de l’origine](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### 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 avoir transmis 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 :
+ `GET`et `HEAD` demandes : si l'origine ne répond pas dans les 30 secondes ou cesse de répondre pendant 30 secondes, CloudFront interrompt la connexion. Si le nombre spécifié de [tentatives de connexion d'origine](DownloadDistValuesOrigin.md#origin-connection-attempts) 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, CloudFront ne réessaie pas tant qu'il ne reçoit pas une autre demande de contenu sur la même origine.
+ `DELETE`,`OPTIONS`, `PATCH``PUT`, 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.
Vous ne pouvez pas modifier le délai de réponse pour une origine Amazon S3 (un compartiment S3 qui *n’est pas* configuré avec un hébergement de site web statique).
### 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 un`Hit`. Pour plus d'informations sur CloudFront les journaux, consultez[CloudFront et journalisation des fonctions Edge](logging.md).
CloudFront réduit uniquement les demandes qui partagent une [*clé de cache*](understanding-the-cache-key.md). 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 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](using-managed-cache-policies.md).
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.
**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](controlling-the-cache-key.md), la [politique de demande d'origine](controlling-origin-requests.md) ou les anciens paramètres de cache.
## Comment CloudFront traite les réponses provenant de votre Amazon S3
Découvrez comment CloudFront traite les réponses provenant de votre Amazon S3 d'origine.
**Contents**
+ [Requêtes annulées](#response-s3-canceled-requests)
+ [En-têtes de réponse HTTP qui CloudFront suppriment ou mettent à jour](#response-s3-removed-headers)
+ [Taille de fichier maximale pouvant être mise en cache](#ResponseS3MaxFileSize)
+ [Redirections](#ResponseS3Redirects)
### 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.
### En-têtes de réponse HTTP qui CloudFront suppriment ou mettent à jour
CloudFront supprime ou met à jour les champs d'en-tête suivants avant de transmettre la réponse de votre origine Amazon S3 au lecteur :
+ `X-Amz-Id-2`
+ `X-Amz-Request-Id`
+ `Set-Cookie`— Si vous configurez CloudFront pour transférer les cookies, le champ `Set-Cookie` d'en-tête sera transmis aux clients. Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md).
+ `Trailer`
+ `Transfer-Encoding`— Si votre origine Amazon S3 renvoie ce champ d'en-tête, CloudFront définissez la valeur sur `chunked` avant de renvoyer la réponse au lecteur.
+ `Upgrade`
+ `Via`— CloudFront définit la valeur suivante dans la réponse au visualiseur :
`Via: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`
Par exemple, la valeur ressemble à ce qui suit :
`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 de plus amples informations, veuillez consulter [Utiliser les demandes de plage pour mettre en cache de large objets](RangeGETs.md#cache-large-objects-with-range-requests).
### Redirections
Vous pouvez configurer un compartiment Amazon S3 pour rediriger toutes les demandes vers un autre nom d’hôte ; il peut s’agir d’un autre compartiment Amazon S3 ou d’un serveur HTTP. Si vous configurez un compartiment pour rediriger toutes les demandes et si le compartiment est l'origine d'une CloudFront distribution, nous vous recommandons de le configurer pour rediriger toutes les demandes vers une CloudFront distribution en utilisant soit le nom de domaine de la distribution (par exemple, d111111abcdef8.cloudfront.net) soit un autre nom de domaine (un CNAME) associé à une distribution (par exemple, exemple.com). Dans le cas contraire, les demandes CloudFront des utilisateurs sont ignorées et les objets sont servis directement depuis la nouvelle origine.
**Note**
Si vous redirigez des demandes vers un nom de domaine alternatif, vous devez également mettre à jour le service DNS pour votre domaine en ajoutant un enregistrement CNAME. Pour plus d’informations, consultez [Utilisez la personnalisation URLs en ajoutant des noms de domaine alternatifs (CNAMEs)](CNAMEs.md).
Voici ce qui se passe lorsque vous configurez un compartiment pour rediriger toutes les demandes :
1. Un utilisateur (par exemple, un navigateur) demande un objet à CloudFront.
1. CloudFront transmet la demande au compartiment Amazon S3 qui est à l'origine de votre distribution.
1. Amazon S3 renvoie un code de statut HTTP 301 (Déplacé de façon permanente), ainsi que le nouvel emplacement.
1. CloudFront met en cache le code d'état de redirection et le nouvel emplacement, et renvoie les valeurs au visualiseur. CloudFront ne suit pas la redirection pour récupérer l'objet depuis le nouvel emplacement.
1. Le visualiseur envoie une autre demande pour l'objet, mais cette fois, il indique le nouvel emplacement d'où il provient CloudFront :
+ Si le compartiment Amazon S3 redirige toutes les demandes vers une CloudFront distribution, en utilisant le nom de domaine de la distribution ou un autre nom de domaine, CloudFront demande l'objet depuis le compartiment Amazon S3 ou le serveur HTTP du nouvel emplacement. Lorsque le nouvel emplacement renvoie l'objet, le CloudFront renvoie au visualiseur et le met en cache dans un emplacement périphérique.
+ Si le compartiment Amazon S3 redirige les demandes vers un autre emplacement, la deuxième demande est ignorée CloudFront. Le compartiment Amazon S3 ou le serveur HTTP du nouvel emplacement renvoie l'objet directement au visualiseur, de sorte que l'objet n'est jamais mis en cache dans un cache CloudFront périphérique.
# 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 :
**Topics**
+ [Comment CloudFront traite et transmet les demandes à votre origine personnalisée](#RequestBehaviorCustomOrigin)
+ [Comment CloudFront traite les réponses provenant de votre origine personnalisée](#ResponseBehaviorCustomOrigin)
## Comment CloudFront traite et transmet les demandes à votre origine personnalisée
Découvrez comment CloudFront traite les demandes des visiteurs et les transmet à votre origine personnalisée.
**Contents**
+ [Authentification](#RequestCustomClientAuth)
+ [Durée de conservation dans le cache et durée de vie minimale](#RequestCustomCaching)
+ [Adresses IP client](#RequestCustomIPAddresses)
+ [Authentification SSL côté client](#RequestCustomClientSideSslAuth)
+ [Compression](#RequestCustomCompression)
+ [Demandes conditionnelles](#RequestCustomConditionalGETs)
+ [Cookies](#RequestCustomCookies)
+ [Partage des ressources cross-origin (CORS)](#request-custom-cors)
+ [Chiffrement](#RequestCustomEncryption)
+ [Demandes GET qui incluent un corps de texte](#RequestCustom-get-body)
+ [Méthodes HTTP](#RequestCustomHTTPMethods)
+ [En-têtes et CloudFront comportement des requêtes HTTP (personnalisés et origines d'Amazon S3)](#request-custom-headers-behavior)
+ [Version de HTTP](#RequestCustomHTTPVersion)
+ [Longueur maximale d’une demande et longueur maximale d’une URL](#RequestCustomMaxRequestStringLength)
+ [OCSP Stapling](#request-custom-ocsp-stapling)
+ [Connexions persistantes](#request-custom-persistent-connections)
+ [Protocoles](#RequestCustomProtocols)
+ [Chaînes de requête](#RequestCustomQueryStrings)
+ [Délai d’attente et tentatives de connexion à l’origine](#custom-origin-timeout-attempts)
+ [Délai de réponse de l’origine](#request-custom-request-timeout)
+ [Demandes simultanées pour le même objet (réduction des demandes)](#request-custom-traffic-spikes)
+ [En-tête `User-Agent`](#request-custom-user-agent-header)
### 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 :
+ `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'`Authorization`en-tête à votre origine
+ CloudFront est configuré pour *ne pas* mettre en cache la réponse aux `OPTIONS` demandes
Pour de plus amples informations, veuillez consulter [Configurer CloudFront pour transférer l'`Authorization`en-tête](add-origin-custom-headers.md#add-origin-custom-headers-forward-authorization).
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](using-https.md).
### 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 plus d’informations, consultez [Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md).
### 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, 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-For`en-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'`X-Forwarded-For`en-tête contient des IPv4 adresses (telles que 192.0.2.44) et des IPv6 adresses (telles que 2001:0 db 8:85 a3 : :8a2e : 0370:7334).
Notez également que l'`X-Forwarded-For`en-tête peut être modifié par chaque nœud sur le chemin vers le serveur actuel (CloudFront). Pour plus d’informations, consultez la section 8.1 de la [RFC 7239](https://datatracker.ietf.org/doc/html/rfc7239). Vous pouvez également modifier l'en-tête à l'aide des fonctions CloudFront Edge Compute.
### Authentification SSL côté client
CloudFront prend en charge l'authentification TLS mutuelle (mTLS) dans le cadre de laquelle le client et le serveur s'authentifient mutuellement à l'aide de certificats. Une fois les MTL configurés, 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 alors que mTLS n'est pas configuré, CloudFront supprime la demande.
Pour plus d'informations sur la configuration des MTL, consultez[Associer une fonction CloudFront de connexion](connection-functions.md).
CloudFront ne prend pas en charge l'authentification client à l'aide de certificats SSL côté client. Si une origine demande un certificat côté client, elle CloudFront supprime la demande.
### Compression
Pour de plus amples informations, veuillez consulter [Diffusion de fichiers compressés](ServingCompressedFiles.md).
### 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-Since`et 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 de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md).
### Cookies
Vous pouvez configurer CloudFront pour transférer les cookies à votre origine. Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md).
### 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'`Origin`en-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](header-caching.md).
### 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 :
+ [Viewer Protocol Policy](DownloadDistValuesCacheBehavior.md#DownloadDistValuesViewerProtocolPolicy)
+ [Protocole (origines personnalisées uniquement)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginProtocolPolicy)
CloudFront transmet les requêtes HTTPS au serveur d'origine à l' SSLv3aide des protocoles 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 vous utilisez la CloudFront console, choisissez les protocoles en cochant les cases **Protocoles SSL d'origine**. Pour de plus amples informations, veuillez consulter [Créer une distribution](distribution-web-creating-console.md).
+ Si vous utilisez l' CloudFront API, spécifiez les protocoles à l'aide de l'`OriginSslProtocols`élément. Pour plus d'informations, consultez [OriginSslProtocols](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_OriginSslProtocols.html)et consultez [DistributionConfig](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_DistributionConfig.html)le *Amazon CloudFront API Reference*.
Si l'origine est un compartiment Amazon S3, la valeur par défaut CloudFront sera TLSv1 .3.
**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, consultez[Utilisez le protocole HTTPS avec CloudFront](using-https.md). 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](secure-connections-supported-viewer-protocols-ciphers.md)
### 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 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.
**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 utiliser`POST`, 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 [Mise en cache de contenu basée sur des en-têtes de demandes](header-caching.md).
| 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` ou`br`, CloudFront transmet un `Accept-Encoding` en-tête normalisé à votre origine. Pour plus d’informations, consultez [Prise en charge de la compression](cache-key-understand-cache-policy.md#cache-policy-compressed-objects) et [Diffusion de fichiers compressés](ServingCompressedFiles.md). | Oui |
| `Accept-Language` | CloudFront supprime l'en-tête. | Oui |
| `Authorization` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html) | 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 de plus amples informations, veuillez consulter [Configuration de la mise en cache en fonction du protocole de la demande](header-caching.md#header-caching-web-protocol). | Oui |
| `CloudFront-Is-Desktop-Viewer` | CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine. Pour de plus amples informations, veuillez consulter [Configuration de la mise en cache en fonction du type d’appareil](header-caching.md#header-caching-web-device). | Oui |
| `CloudFront-Is-Mobile-Viewer` | CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine. Pour de plus amples informations, veuillez consulter [Configuration de la mise en cache en fonction du type d’appareil](header-caching.md#header-caching-web-device). | Oui |
| `CloudFront-Is-Tablet-Viewer` | CloudFront n'ajoute pas l'en-tête avant de transmettre la demande à votre origine. Pour de plus amples informations, veuillez consulter [Configuration de la mise en cache en fonction du type d’appareil](header-caching.md#header-caching-web-device). | 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'`Cookie`en-tête sera redirigé vers votre origine. Dans le cas contraire, CloudFront supprime le champ `Cookie` d'en-tête. Pour de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md). | 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 de plus amples informations, veuillez consulter [Comment CloudFront traite les demandes partielles pour un objet (plage GETs)](RangeGETs.md). | 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 par`Amazon CloudFront`. Si vous souhaitez CloudFront mettre en cache votre contenu en fonction de l'appareil utilisé par l'utilisateur, consultez[Configuration de la mise en cache en fonction du type d’appareil](header-caching.md#header-caching-web-device). | 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 de plus amples informations, veuillez consulter [Adresses IP client](#RequestCustomIPAddresses). | 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 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 requête. 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) au visualiseur. 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 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 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. 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 et VPC uniquement)](DownloadDistValuesOrigin.md#DownloadDistValuesOriginKeepaliveTimeout) dans la section [Référence de tous les paramètres de distribution](distribution-web-values-specify.md).
### 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 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.
**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, consultez[Mettre à jour une distribution](HowToUpdateDistribution.md). Pour plus d'informations sur la mise à jour d'une distribution à l'aide de l' CloudFront API, [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)consultez 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 de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur les paramètres de chaîne de requête](QueryStringParameters.md).
### 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 plus d’informations, consultez [Contrôle des délais d’expiration et des tentatives de l’origine](high_availability_origin_failover.md#controlling-attempts-and-timeouts).
### 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 avoir transmis 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 :
+ `GET`et `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](DownloadDistValuesOrigin.md#origin-connection-attempts) 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, CloudFront ne réessaie pas tant qu'il ne reçoit pas une autre demande de contenu sur la même origine.
+ `DELETE`,`OPTIONS`, `PATCH``PUT`, et `POST` demandes : si l'origine ne répond pas pendant le délai de lecture, interrompt CloudFront la connexion et n'essaie plus de contacter l'origine. Le client peut soumettre à nouveau la demande si nécessaire.
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](DownloadDistValuesOrigin.md#DownloadDistValuesOriginResponseTimeout).
### 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 un`Hit`. Pour plus d'informations sur CloudFront les journaux, consultez[CloudFront et journalisation des fonctions Edge](logging.md).
CloudFront réduit uniquement les demandes qui partagent une [*clé de cache*](understanding-the-cache-key.md). 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 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](using-managed-cache-policies.md).
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.
**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](controlling-the-cache-key.md), la [politique de demande d'origine](controlling-origin-requests.md) 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-Agent`en-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 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, consultez[Mise en cache de contenu basée sur des en-têtes de demandes](header-caching.md).
Vous pouvez configurer CloudFront pour mettre en cache des objets en fonction des valeurs de l'`User-Agent`en-tête, mais nous ne le recommandons pas. L'`User-Agent`en-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-Agent`en-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.
**Contents**
+ [Réponses `100 Continue`](#Response100Continue)
+ [Mise en cache](#ResponseCustomCaching)
+ [Requêtes annulées](#response-custom-canceled-requests)
+ [Négociation de contenu](#ResponseCustomContentNegotiation)
+ [Cookies](#ResponseCustomCookies)
+ [Connexions TCP annulées](#ResponseCustomDroppedTCPConnections)
+ [En-têtes de réponse HTTP qui CloudFront suppriment ou remplacent](#ResponseCustomRemovedHeaders)
+ [Taille de fichier maximale pouvant être mise en cache](#ResponseCustomMaxFileSize)
+ [Origine non disponible](#ResponseCustomOriginUnavailable)
+ [Redirections](#ResponseCustomRedirects)
+ [En-tête `Transfer-Encoding`](#ResponseCustomTransferEncoding)
### Réponses `100 Continue`
Votre origine ne peut pas envoyer plus d'une réponse 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)](#request-custom-traffic-spikes).
### 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` ou`If-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'`Vary`en-tête comme décrit dans[En-têtes de réponse HTTP qui CloudFront suppriment ou remplacent](#ResponseCustomRemovedHeaders).
### 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](Cookies.md).
### 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-Length`en-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 en-tête `Content-Length`, CloudFront ne peut pas déterminer si la connexion TCP a été est annulée délibérément ou par erreur.
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 de plus amples informations, veuillez consulter [Mise en cache de contenu basée sur des cookies](Cookies.md).
+ `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-Viewer``CloudFront-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 de plus amples informations, veuillez consulter [Configuration de la mise en cache en fonction du type d’appareil](header-caching.md#header-caching-web-device).
+ Si vous configurez votre origine pour inclure l'un `Accept-Encoding` ou l'autre `Cookie` dans l'`Vary`en-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'`Vary`en-tête (par exemple,`Vary:Accept-Charset,Accept-Language`), CloudFront renvoie l'`Vary`en-tête avec ces valeurs au visualiseur.
+ Pour plus d'informations sur CloudFront le traitement d'une valeur de `*` dans l'`Vary`en-tête, consultez[Négociation de contenu](#ResponseCustomContentNegotiation).
+ Si vous configurez votre origine pour inclure d'autres valeurs dans l'`Vary`en-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: `*http-version* *alphanumeric-string*`.cloudfront.net (CloudFront)`
Par exemple, la valeur ressemble à ce qui suit :
`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 de plus amples informations, veuillez consulter [Utiliser les demandes de plage pour mettre en cache de large objets](RangeGETs.md#cache-large-objects-with-range-requests).
### 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, consultez[Comment CloudFront traite les erreurs lorsque vous avez configuré des pages d'erreur personnalisées](HTTPStatusCodes.md#HTTPStatusCodes-custom-error-pages).
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 CloudFront et se dirige directement vers l'URL d'origine. Par conséquent, nous vous recommandons de ne pas rediriger des demandes vers la nouvelle URL de l’objet sur l’origine.
+ La nouvelle CloudFront URL de l'objet. Lorsque le visualiseur 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 occasionne des frais pour deux demandes à CloudFront.
### En-tête `Transfer-Encoding`
CloudFront ne prend en charge que la `chunked` valeur de l'`Transfer-Encoding`en-tête. Si votre origine revient`Transfer-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 revient`Transfer-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](#ResponseCustomDroppedTCPConnections).
# Comportement des requêtes et des réponses pour les groupes d’origine
Les demandes adressées à un groupe d’origine fonctionnent de la même manière que celles d’une origine qui n’est pas configurée comme un groupe d’origine, sauf en cas de basculement d’origine. Comme pour toute autre origine, lorsqu'il CloudFront reçoit une demande et que le contenu est déjà mis en cache dans un emplacement périphérique, le contenu est diffusé aux spectateurs à partir du cache. En l’absence de cache et lorsque l’origine est un groupe d’origine, les demandes de l’utilisateur sont transférées à l’origine principale dans le groupe d’origine.
Le comportement de demande et de réponse pour l’origine principale est le même que pour une origine qui n’est pas incluse dans un groupe d’origine. Pour plus d’informations, consultez [Comportement des demandes et des réponses pour les origines Amazon S3 Origins](RequestAndResponseBehaviorS3Origin.md) et [Comportement des demandes et des réponses pour les origines personnalisées](RequestAndResponseBehaviorCustomOrigin.md).
La section suivante décrit le comportement du basculement d’origine lorsque l’origine principale renvoie des codes de statut HTTP spécifiques :
+ Code d'état HTTP 2xx (succès) : CloudFront met le fichier en cache et le renvoie au visualiseur.
+ Code d'état HTTP 3xx (redirection) : CloudFront renvoie le code d'état au visualiseur.
+ Code d'état HTTP 4xx ou 5xx (erreur client/serveur) : si le code d'état renvoyé a été configuré pour le basculement, CloudFront envoie la même demande à l'origine secondaire dans le groupe d'origine.
+ Code d'état HTTP 4xx ou 5xx (erreur client/serveur) : si le code d'état renvoyé n'a pas été configuré pour le basculement, CloudFront renvoie l'erreur au visualiseur.
CloudFront bascule vers l'origine secondaire uniquement lorsque la méthode HTTP de la demande du spectateur est `GET``HEAD`, ou`OPTIONS`. CloudFront ne bascule pas lorsque le visualiseur envoie une autre méthode HTTP (par exemple `POST``PUT`, etc.).
Lorsque CloudFront vous envoyez une demande à une origine secondaire, le comportement de réponse est le même que pour une CloudFront origine ne faisant pas partie d'un groupe d'origine.
Pour plus d’informations sur les groupes d’origine, consultez [Optimisez la haute disponibilité grâce au basculement CloudFront d'origine](high_availability_origin_failover.md).
# Ajout d’en-têtes personnalisés aux demandes d’origine
Vous pouvez configurer CloudFront pour ajouter des en-têtes personnalisés aux demandes qu'il envoie à votre origine. Les en-têtes personnalisés vous permettent d’envoyer et de récupérer des informations auprès de votre origine, données que les demandes d’utilisateur standard ne transmettent pas. Vous pouvez même personnaliser les en-têtes pour chaque origine. CloudFrontprend en charge les en-têtes personnalisés pour les origines personnalisées et les origines Amazon S3.
**Contents**
+ [Cas d’utilisation](#add-origin-custom-headers-use-cases)
+ [Configurer CloudFront pour ajouter des en-têtes personnalisés aux demandes d'origine](#add-origin-custom-headers-configure)
+ [En-têtes personnalisés qui ne CloudFront peuvent pas être ajoutés aux demandes d'origine](#add-origin-custom-headers-denylist)
+ [Configurer CloudFront pour transférer l'`Authorization`en-tête](#add-origin-custom-headers-forward-authorization)
## Cas d’utilisation
Vous pouvez ajouter des en-têtes personnalisés, comme ceux présentés ci-dessous :
**Identifier les demandes provenant de CloudFront**
Vous pouvez identifier les demandes provenant de votre origine CloudFront. Cela peut être utile si vous souhaitez savoir si les utilisateurs CloudFront contournent ou si vous utilisez plusieurs CDN et souhaitez obtenir des informations sur les demandes provenant de chaque CDN.
Si vous utilisez une origine Amazon S3 avec [journalisation des accès au serveur Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html) activée, les journaux n'incluent pas les informations d'en-tête.
**Détermination des demandes provenant d'une distribution particulière**
Si vous configurez plusieurs CloudFront distributions pour utiliser la même origine, vous pouvez ajouter des en-têtes personnalisés différents dans chaque distribution. Vous pouvez alors utiliser les journaux de votre origine pour déterminer quelles demandes proviennent de quelle distribution CloudFront.
**Activation du partage des ressources de plusieurs origines (CORS)**
Si certains de vos utilisateurs ne prennent pas en charge le partage de ressources entre origines (CORS), vous pouvez configurer CloudFront pour toujours ajouter l'`Origin`en-tête aux demandes qu'il envoie à votre source. Ensuite, vous pouvez configurer votre origine pour renvoyer l'en-tête `Access-Control-Allow-Origin` pour chaque demande. Vous devez également [configurer CloudFront pour respecter les paramètres CORS](header-caching.md#header-caching-web-cors).
**Contrôle de l'accès au contenu**
Vous pouvez utiliser les en-têtes personnalisés pour contrôler l'accès au contenu. En configurant votre origine pour répondre aux demandes uniquement lorsqu'elles incluent un en-tête personnalisé ajouté par CloudFront, vous empêchez les utilisateurs de contourner CloudFront et d'accéder à votre contenu directement sur l'origine. Pour de plus amples informations, veuillez consulter [Restriction de l’accès à des fichiers d’origines personnalisées](private-content-overview.md#forward-custom-headers-restrict-access).
## Configurer CloudFront pour ajouter des en-têtes personnalisés aux demandes d'origine
Pour configurer une distribution afin d'ajouter des en-têtes personnalisés aux demandes qu'elle envoie à votre origine, mettez à jour la configuration de l'origine via l'une des méthodes suivantes :
+ **CloudFront console** — Lorsque vous créez ou mettez à jour une distribution, spécifiez les noms et les valeurs des en-têtes dans les paramètres **Ajouter des en-têtes personnalisés**. Pour de plus amples informations, veuillez consulter [Ajout d'en-tête personnalisé](DownloadDistValuesOrigin.md#DownloadDistValuesOriginCustomHeaders).
+ **CloudFront API** — Pour chaque origine à laquelle vous souhaitez ajouter des en-têtes personnalisés, spécifiez les noms et les valeurs des en-têtes dans le `CustomHeaders` champ intérieur`Origin`. Pour plus d'informations, consultez [CreateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CreateDistribution.html)ou consultez [UpdateDistribution](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_UpdateDistribution.html)le *Amazon CloudFront API Reference*.
Si les noms et valeurs d'en-tête que vous spécifiez ne sont pas déjà présents dans la demande de visualisation, CloudFront ajoutez-les à la demande d'origine. Si un en-tête est présent, CloudFront remplace la valeur de l'en-tête avant de transmettre la demande à l'origine.
Pour connaître les quotas qui s’appliquent aux en-têtes personnalisés d’origine, consultez [Quotas sur les en-têtes](cloudfront-limits.md#limits-custom-headers).
## En-têtes personnalisés qui ne CloudFront peuvent pas être ajoutés aux demandes d'origine
Vous ne pouvez pas configurer CloudFront pour ajouter l'un des en-têtes suivants aux demandes qu'il envoie à votre origine :
+ `Cache-Control`
+ `Connection`
+ `Content-Length`
+ `Cookie`
+ `Host`
+ `If-Match`
+ `If-Modified-Since`
+ `If-None-Match`
+ `If-Range`
+ `If-Unmodified-Since`
+ `Max-Forwards`
+ `Pragma`
+ `Proxy-Authenticate`
+ `Proxy-Authorization`
+ `Proxy-Connection`
+ `Range`
+ `Request-Range`
+ `TE`
+ `Trailer`
+ `Transfer-Encoding`
+ `Upgrade`
+ `Via`
+ En-têtes commençant par `X-Amz-`
+ En-têtes commençant par `X-Edge-`
+ `X-Real-Ip`
## Configurer CloudFront pour transférer l'`Authorization`en-tête
Lorsque CloudFront vous transférez une demande d'utilisateur à votre source, certains CloudFront en-têtes de visionnage sont supprimés par défaut, y compris l'`Authorization`en-tête. Pour vous assurer que votre origine reçoit toujours l’en-tête `Authorization` dans les demandes d’origine, vous disposez des options suivantes :
+ Ajoutez l'en-tête `Authorization` à la clé de cache à l'aide d'une stratégie de cache. Tous les en-têtes de la clé de cache sont automatiquement inclus dans les demandes d’origine. Pour plus d’informations, consultez [Contrôle de la clé de cache à l’aide d’une politique](controlling-the-cache-key.md).
+ Utilisez une stratégie de demande d’origine qui transfère tous les en-têtes d’utilisateurs à l’origine. Vous ne pouvez pas transférer l'`Authorization`en-tête individuellement dans une politique de demande d'origine, mais lorsque vous transférez tous les en-têtes du lecteur, l'`Authorization`en-tête est CloudFront inclus dans les demandes du lecteur. CloudFront fournit une politique de demande d'origine gérée pour ce cas d'utilisation, appelée **Managed- AllViewer**. Pour de plus amples informations, veuillez consulter [Utilisation des stratégies de demande d’origine gérées](using-managed-origin-request-policies.md).
# Comment CloudFront traite les demandes partielles pour un objet (plage GETs)
Pour un objet large, l’utilisateur (navigateur web ou autre client) peut effectuer plusieurs demandes `GET` et utiliser l’en-tête de demande `Range` pour télécharger l’objet en parties plus petites. Ces demandes de plages d’octets, parfois appelées demandes `Range GET`, améliore l’efficacité des téléchargements partiels et la récupération de transferts ayant partiellement échoué.
Lorsqu'il CloudFront reçoit une `Range GET` demande, il vérifie le cache à l'emplacement périphérique qui a reçu la demande. Si le cache situé à cet emplacement périphérique contient déjà l'objet entier ou la partie demandée de l'objet, CloudFront diffuse immédiatement la plage demandée depuis le cache.
Si le cache ne contient pas la plage demandée, CloudFront transmet la demande à l'origine. (Pour optimiser les performances, vous CloudFront pouvez demander une plage plus large que celle demandée par le client dans le`Range GET`.) Ce qui se produit dépend de si l’origine prend en charge les demandes `Range GET` :
+ **Si l'origine prend en charge les `Range GET` demandes**, elle renvoie la plage demandée. CloudFront sert la plage demandée et la met également en cache pour les demandes futures. (Amazon S3 prend en charge les demandes `Range GET`, tout comme de nombreux serveurs HTTP.)
+ **Si l'origine ne prend pas en charge les `Range GET` demandes**, elle renvoie l'objet entier. CloudFront répond à la demande en cours en envoyant l'objet entier tout en le mettant en cache pour les demandes futures. Après avoir mis en CloudFront cache l'objet entier dans un cache périphérique, il répond aux nouvelles `Range GET` demandes en fournissant la plage demandée.
Dans les deux cas, CloudFront commence à servir la plage ou l'objet demandé à l'utilisateur final dès que le premier octet arrive depuis l'origine.
**Note**
Si le visualiseur fait une `Range GET` demande et que l'origine revient`Transfer-Encoding: chunked`, CloudFront renvoie l'objet entier au visualiseur au lieu de la plage demandée.
CloudFront suit généralement la spécification RFC pour l'`Range`en-tête. Cependant si vos en-têtes `Range` ne respectent pas les exigences suivantes, CloudFront renvoie un code de statut HTTP `200` avec l'objet entier au lieu du code de statut `206` avec les plages spécifiées :
+ Les plages doivent être répertoriées en ordre croissant. Par exemple, `100-200,300-400` est valide, mais pas `300-400,100-200`.
+ Les plages ne doivent pas se chevaucher. Par exemple, `100-200,150-250` n’est pas valide.
+ Toutes les spécifications de plages doivent être valides. Par exemple, vous ne pouvez pas spécifier une valeur négative dans une plage.
Pour plus d’informations sur l’en-tête de demande `Range`, consultez la section [Demandes de plage](https://httpwg.org/specs/rfc7233.html#range.requests) dans RFC 7233, ou [Plage](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range) dans MDN Web Docs.
## Utiliser les demandes de plage pour mettre en cache de large objets
Lorsque la mise en cache est activée, CloudFront elle ne récupère ni ne met en cache un objet de plus de 50 Go. Lorsqu'une origine indique que l'objet est plus grand que cette taille (dans l'en-tête de `Content-Length` réponse), CloudFront ferme la connexion à l'origine et renvoie une erreur au visualiseur. (Lorsque la mise en cache est désactivée, CloudFront vous pouvez récupérer un objet dont la taille est supérieure à cette taille depuis l'origine et le transmettre au visualiseur. Cependant, CloudFront ne met pas en cache l'objet.)
Cependant, avec les demandes de plage, vous pouvez les utiliser CloudFront pour mettre en cache un objet dont la taille de fichier est supérieure à la [taille de fichier maximale pouvant être mise en cache](cloudfront-limits.md#limits-web-distributions).
**Example Exemple**
1. Prenons l’exemple d’une origine contenant un objet de 100 Go. Lorsque la mise en cache est activée, CloudFront aucun objet de cette taille ne peut être récupéré ou mis en cache. Toutefois, l’utilisateur peut envoyer plusieurs demandes de plage pour récupérer cet objet par parties, chacune d’entre elles étant inférieure à 50 Go.
1. L’utilisateur peut demander l’objet dans des parties de 20 Go en envoyant une demande avec l’en-tête `Range: bytes=0-21474836480` pour récupérer la première partie, une autre demande avec l’en-tête `Range: bytes=21474836481-42949672960` pour récupérer la partie suivante, etc.
1. Lorsque l’utilisateur a reçu toutes les parties, il peut les combiner pour construire l’objet d’origine de 100 Go.
1. Dans ce cas, met en CloudFront cache chacune des parties de 20 Go de l'objet et peut répondre aux demandes ultérieures pour la même partie à partir du cache.
Pour une demande de plage sur un objet compressé, la demande de plage d’octets se base sur la taille compressée, et non sur la taille originale de l’objet. Pour plus d’informations sur la compression des fichiers, consultez [Diffusion de fichiers compressés](ServingCompressedFiles.md).
# Comment CloudFront traite les codes d'état HTTP 3xx de votre origine
Lorsque CloudFront vous demandez un objet depuis votre compartiment Amazon S3 ou votre serveur d'origine personnalisé, votre origine renvoie parfois un code d'état HTTP 3xx. Ce message indique généralement l’une des situations suivantes :
+ L’URL de l’objet a changé (par exemple, les codes d’état 301, 302, 307 ou 308)
+ L'objet n'a pas changé depuis la dernière fois que vous l'avez CloudFront demandé (code d'état 304)
CloudFront met en cache 3xx réponses en fonction des paramètres de votre CloudFront distribution et des en-têtes de la réponse. CloudFront met en cache 307 et 308 réponses uniquement lorsque vous incluez l'`Cache-Control`en-tête dans les réponses depuis l'origine. Pour de plus amples informations, veuillez consulter [Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md).
Si votre origine renvoie un code d'état de redirection (par exemple, 301 ou 307), CloudFront il ne suit pas la redirection. CloudFront transmet la réponse 301 ou 307 au spectateur, qui peut suivre la redirection en envoyant une nouvelle demande.
# Comment CloudFront traite les codes d'état HTTP 4xx et 5xx de votre origine
Lorsque CloudFront vous demandez un objet depuis votre compartiment Amazon S3 ou votre serveur d'origine personnalisé, votre origine renvoie parfois un code d'état HTTP 4xx ou 5xx, qui indique qu'une erreur s'est produite. CloudFront le comportement dépend de :
+ Si vous avez configuré des pages d’erreur personnalisées
+ Si vous avez configuré la durée pendant laquelle vous souhaitez mettre CloudFront en cache les réponses aux erreurs depuis votre origine (TTL minimum de mise en cache des erreurs)
+ Le code d’état
+ Pour les codes d'état 5xx, si l'objet demandé se trouve actuellement dans le cache CloudFront périphérique
+ Pour certains codes d’état 4xx, si l’origine renvoie un en-tête `Cache-Control max-age` ou `Cache-Control s-maxage`
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.
Si l'origine ne répond pas, la CloudFront demande envoyée à l'origine expire, ce qui est considéré comme une erreur HTTP 5xx de la part de l'origine, même si l'origine n'a pas répondu avec cette erreur. Dans ce scénario, CloudFront continue de diffuser le contenu mis en cache. Pour de plus amples informations, veuillez consulter [Origine non disponible](RequestAndResponseBehaviorCustomOrigin.md#ResponseCustomOriginUnavailable).
Si vous avez activé la journalisation, CloudFront écrit les résultats dans les journaux quel que soit le code d'état HTTP.
Pour plus d'informations sur les fonctionnalités et les options liées au message d'erreur renvoyé par CloudFront, consultez les rubriques suivantes :
+ Pour plus d'informations sur les paramètres des pages d'erreur personnalisées dans la CloudFront console, consultez[Pages d’erreur personnalisées et mise en cache des erreurs](DownloadDistValuesErrorPages.md).
+ Pour plus d'informations sur les erreurs liées à la mise en cache du TTL minimum dans la CloudFront console, consultez. [Erreur de mise en cache de TTL minimum (secondes)](DownloadDistValuesErrorPages.md#DownloadDistValuesErrorCachingMinTTL)
+ Pour obtenir la liste des codes d'état HTTP mis en CloudFront cache, consultez[Codes d'état HTTP 4xx et 5xx mis en cache CloudFront](#HTTPStatusCodes-cached-errors).
**Topics**
+ [Comment CloudFront traite les erreurs lorsque vous avez configuré des pages d'erreur personnalisées](#HTTPStatusCodes-custom-error-pages)
+ [Comment CloudFront traite les erreurs si vous n'avez pas configuré de pages d'erreur personnalisées](#HTTPStatusCodes-no-custom-error-pages)
+ [Codes d'état HTTP 4xx et 5xx mis en cache CloudFront](#HTTPStatusCodes-cached-errors)
## Comment CloudFront traite les erreurs lorsque vous avez configuré des pages d'erreur personnalisées
Si vous avez configuré des pages d'erreur personnalisées, CloudFront le comportement dépend de la présence ou non de l'objet demandé dans le cache périphérique.
### L’objet demandé n’est pas dans le cache périphérique
CloudFront continue d'essayer d'obtenir l'objet demandé depuis votre origine lorsque toutes les conditions suivantes sont remplies :
+ Un utilisateur demande un objet.
+ L’objet n’est pas dans le cache périphérique.
+ L’origine renvoie un code de statut HTTP 4xx ou 5xx et l’une des conditions suivantes est vraie :
+ L’origine renvoie un code de statut HTTP 5xx à la place d’un code de statut 304 (Non modifié) ou une version mise à jour de l’objet.
+ L’origine renvoie un code de statut HTTP 4xx qui n’est pas limité par un en-tête de contrôle de cache et est inclus dans la liste suivante de codes de statut: [Codes d'état HTTP 4xx et 5xx mis en cache CloudFront](#HTTPStatusCodes-cached-errors).
+ L’origine renvoie un code d’état HTTP 4xx sans en-tête `Cache-Control max-age` ou sans en-tête `Cache-Control s-maxage`, et le code d’état est inclus dans la liste suivante de codes d’état : Control [Codes d'état HTTP 4xx mis en CloudFront cache en fonction des en-têtes `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
**CloudFront effectue les opérations suivantes :**
1. Dans le cache CloudFront périphérique qui a reçu la demande du lecteur, CloudFront vérifie la configuration de votre distribution et obtient le chemin de la page d'erreur personnalisée correspondant au code d'état renvoyé par votre origine.
1. CloudFront trouve le premier comportement de cache de votre distribution dont le modèle de chemin correspond au chemin de la page d'erreur personnalisée.
1. L'emplacement CloudFront périphérique envoie une demande de page d'erreur personnalisée à l'origine spécifiée dans le comportement du cache.
1. L’origine renvoie la page d’erreur personnalisée à l’emplacement périphérique.
1. CloudFront renvoie la page d'erreur personnalisée à l'afficheur qui a fait la demande, et met également en cache la page d'erreur personnalisée pour le maximum des valeurs suivantes :
+ La durée spécifiée par la durée de vie minimale (TTL) de la mise en cache des erreurs (10 secondes par défaut)
+ La durée spécifiée par un en-tête `Cache-Control max-age` ou un en-tête `Cache-Control s-maxage` qui est renvoyé par l’origine lorsque la première demande a généré l’erreur
1. Une fois le temps de mise en cache (déterminé à l'étape 5) écoulé, CloudFront essaie à nouveau d'obtenir l'objet demandé en transférant une autre demande à votre origine. CloudFront continue de réessayer aux intervalles spécifiés par le TTL minimum de mise en cache des erreurs.
**Note**
Si vous avez également configuré un comportement de cache pour la même page d'erreur personnalisée, CloudFront utilisez plutôt le comportement de cache TTL. Dans ce cas, CloudFront procédez comme suit pour les étapes 5 et 6 :
Après avoir CloudFront renvoyé la page d'erreur personnalisée au visualiseur qui a fait la demande, CloudFront vérifie le comportement du cache TTL (par exemple, vous définissez le TTL par défaut sur 5 secondes). CloudFront met ensuite en cache la page d'erreur personnalisée jusqu'à ce maximum.
Au bout de 5 secondes, CloudFront récupère à nouveau la page d'erreur personnalisée depuis l'origine. CloudFront continuera à réessayer aux intervalles spécifiés par le comportement du cache TTL.
Pour plus d’informations, consultez [Paramètres de durée de vie](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMinTTL) du comportement de cache.
### L’objet demandé est dans le cache périphérique
CloudFront continue à servir l'objet qui se trouve actuellement dans le cache périphérique lorsque toutes les conditions suivantes sont réunies :
+ Un utilisateur demande un objet.
+ L’objet se trouve dans le cache périphérique, mais il a expiré
+ L’origine renvoie un code de statut HTTP 5xx à la place d’un code de statut 304 (Non modifié) ou une version mise à jour de l’objet.
**CloudFront effectue les opérations suivantes :**
1. Si votre origine renvoie un code de statut 5xx, il CloudFront sert l'objet même s'il a expiré. Pendant la durée de l'erreur de mise en cache, le TTL minimum CloudFront continue de répondre aux demandes des utilisateurs en servant l'objet depuis le cache périphérique.
Si votre origine renvoie un code de statut 4xx, CloudFront retourne le code de statut, et non l'objet demandé, à l'utilisateur.
1. Une fois que le TTL minimum de mise en cache d'erreur est expiré, CloudFront essaie à nouveau d'obtenir l'objet demandé en transférant une autre demande à votre origine. Notez que si l'objet n'est pas fréquemment demandé, cela CloudFront peut l'expulser du cache périphérique alors que votre serveur d'origine renvoie encore 5xx réponses. Pour plus d'informations sur la durée pendant laquelle les objets restent dans les caches CloudFront périphériques, consultez[Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md).
## Comment CloudFront traite les erreurs si vous n'avez pas configuré de pages d'erreur personnalisées
Si vous n'avez pas configuré de pages d'erreur personnalisées, CloudFront le comportement dépend de la présence ou non de l'objet demandé dans le cache périphérique.
**Topics**
+ [L’objet demandé n’est pas dans le cache périphérique](#HTTPStatusCodes-no-custom-error-pages-not-in-cache)
+ [L’objet demandé est dans le cache périphérique](#HTTPStatusCodes-no-custom-error-pages-in-cache)
### L’objet demandé n’est pas dans le cache périphérique
CloudFront continue d'essayer d'obtenir l'objet demandé depuis votre origine lorsque toutes les conditions suivantes sont remplies :
+ Un utilisateur demande un objet.
+ L’objet n’est pas dans le cache périphérique.
+ L’origine renvoie un code de statut HTTP 4xx ou 5xx et l’une des conditions suivantes est vraie :
+ L’origine renvoie un code de statut HTTP 5xx à la place d’un code de statut 304 (Non modifié) ou une version mise à jour de l’objet.
+ L’origine renvoie un code de statut HTTP 4xx qui n’est pas limité par un en-tête de contrôle de cache et est inclus dans la liste suivante de codes de statut: [Codes d'état HTTP 4xx et 5xx mis en cache CloudFront](#HTTPStatusCodes-cached-errors)
+ L’origine renvoie un code d’état HTTP 4xx sans en-tête `Cache-Control max-age` ou sans en-tête `Cache-Control s-maxage`, et le code d’état est inclus dans la liste suivante de codes d’état : Control [Codes d'état HTTP 4xx mis en CloudFront cache en fonction des en-têtes `Cache-Control`](#HTTPStatusCodes-cached-errors-with-cache-control).
CloudFront effectue les opérations suivantes :
1. CloudFront renvoie le code d'état 4xx ou 5xx au visualiseur, et met également en cache le code d'état dans le cache périphérique qui a reçu la demande pour le maximum des éléments suivants :
+ La durée spécifiée par la durée de vie minimale (TTL) de la mise en cache des erreurs (10 secondes par défaut)
+ La durée spécifiée par un en-tête `Cache-Control max-age` ou un en-tête `Cache-Control s-maxage` qui est renvoyé par l’origine lorsque la première demande a généré l’erreur
1. Pendant la durée de mise en cache (déterminée à l'étape 1), CloudFront répond aux demandes d'utilisateur suivantes pour le même objet avec le code de statut 4xx ou 5xx mis en cache.
1. Une fois le temps de mise en cache (déterminé à l'étape 1) écoulé, CloudFront essaie à nouveau d'obtenir l'objet demandé en transférant une autre demande à votre origine. CloudFront continue de réessayer aux intervalles spécifiés par le TTL minimum de mise en cache des erreurs.
### L’objet demandé est dans le cache périphérique
CloudFront continue à servir l'objet qui se trouve actuellement dans le cache périphérique lorsque toutes les conditions suivantes sont réunies :
+ Un utilisateur demande un objet.
+ L’objet se trouve dans le cache périphérique, mais il a expiré Cela signifie que l’objet est *obsolète*.
+ L’origine renvoie un code de statut HTTP 5xx à la place d’un code de statut 304 (Non modifié) ou une version mise à jour de l’objet.
CloudFront effectue les opérations suivantes :
1. Si votre origine renvoie un code d'erreur 5xx, CloudFront sert l'objet même s'il a expiré. Pendant la durée de l'erreur de mise en cache, le TTL minimum (10 secondes par défaut) CloudFront continue de répondre aux demandes des utilisateurs en diffusant l'objet depuis le cache périphérique.
Si votre origine renvoie un code de statut 4xx, CloudFront retourne le code de statut, et non l'objet demandé, à l'utilisateur.
1. Une fois que le TTL minimum de mise en cache d'erreur est expiré, CloudFront essaie à nouveau d'obtenir l'objet demandé en transférant une autre demande à votre origine. Si l'objet n'est pas fréquemment demandé, il est CloudFront possible de l'expulser du cache périphérique alors que votre serveur d'origine renvoie encore 5xx réponses. Pour de plus amples informations, veuillez consulter [Gestion de la durée de conservation de contenu dans le cache (expiration)](Expiration.md).
**Astuce**
Si vous configurez la directive `stale-if-error` ou `Stale-While-Revalidate`, vous pouvez spécifier la durée pendant laquelle les objets obsolètes restent disponibles dans le cache périphérique. Vous pouvez ainsi continuer à diffuser du contenu à vos utilisateurs même lorsque votre origine n’est pas disponible. Pour plus d'informations, consultez [Diffusion de contenu obsolète (expiré)](Expiration.md#stale-content).
CloudFront ne servira qu'un objet périmé jusqu'à la valeur [TTL maximale](DownloadDistValuesCacheBehavior.md#DownloadDistValuesMaxTTL) spécifiée. Après cette durée, l’objet ne sera plus disponible dans le cache périphérique.
## Codes d'état HTTP 4xx et 5xx mis en cache CloudFront
CloudFront met en cache les codes de statut HTTP 4xx et 5xx renvoyés par votre origine, en fonction du code d'état spécifique renvoyé et du fait que votre origine renvoie ou non des en-têtes spécifiques dans la réponse.
CloudFront met en cache les codes de statut HTTP 4xx et 5xx suivants renvoyés par votre origine. Si vous avez configuré une page d'erreur personnalisée pour un code d'état HTTP, la page d'erreur personnalisée est mise en CloudFront cache.
**Note**
Si vous utilisez la politique de cache [CachingDisabled](using-managed-cache-policies.md#managed-cache-policy-caching-disabled) géré, ces codes d'état ou pages d'erreur personnalisées CloudFront ne seront pas mis en cache.
| | |
| --- |--- |
| 404 | Introuvable |
| 414 | URI de demande trop longue |
| 500 | Erreur de serveur interne |
| 501 | Non implémenté |
| 502 | Passerelle erronée |
| 503 | Service non disponible |
| 504 | Délai de passerelle expiré |
### Codes d'état HTTP 4xx mis en CloudFront cache en fonction des en-têtes `Cache-Control`
CloudFront ne met en cache les codes de statut HTTP 4xx suivants renvoyés par votre origine que si votre origine renvoie un en-tête `Cache-Control max-age` ou`Cache-Control s-maxage`. Si vous avez configuré une page d'erreur personnalisée pour l'un de ces codes d'état HTTP et que votre origine renvoie l'un des en-têtes de contrôle du cache, met en CloudFront cache la page d'erreur personnalisée.
| | |
| --- |--- |
| 400 | Demande erronée |
| 403 | Accès interdit |
| 405 | Méthode non autorisée |
| 412¹ | Échec de condition préalable |
| 415¹ | Type de support non pris en charge |
¹ CloudFront ne prend pas en charge la création de pages d'erreur personnalisées pour ces codes d'état HTTP.
# Génération de réponses aux·erreurs personnalisées
Si un objet que vous diffusez n' CloudFront est pas disponible pour une raison quelconque, votre serveur Web renvoie généralement un code d'état HTTP pertinent CloudFront pour l'indiquer. Par exemple, si un utilisateur demande une URL non valide, votre serveur Web renvoie un code d'état HTTP 404 (Introuvable) à CloudFront, puis le CloudFront renvoie au lecteur. Au lieu d'utiliser cette réponse d'erreur par défaut, vous pouvez en créer une personnalisée qui sera CloudFront renvoyée au lecteur.
Si vous configurez CloudFront pour renvoyer une page d'erreur personnalisée pour un code d'état HTTP mais que la page d'erreur personnalisée n'est pas disponible, CloudFront renvoie au lecteur le code d'état CloudFront reçu de l'origine contenant les pages d'erreur personnalisées. Supposons, par exemple, que votre origine personnalisée renvoie un code de statut 500 et que vous ayez configuré CloudFront pour obtenir une page d'erreur personnalisée pour un code de statut 500 provenant d'un compartiment Amazon S3. Cependant, quelqu'un a accidentellement supprimé la page d'erreur personnalisée de votre compartiment Amazon S3. CloudFront renvoie un code d'état HTTP 404 (Not Found) au visualiseur qui a demandé l'objet.
Lorsque vous CloudFront renvoyez une page d'erreur personnalisée à un lecteur, vous payez les CloudFront frais standard pour la page d'erreur personnalisée, et non les frais pour l'objet demandé. Pour plus d'informations sur les CloudFront frais, consultez [Amazon CloudFront Pricing](https://aws.amazon.com/cloudfront/pricing/).
**Topics**
+ [Configuration du comportement de réponses aux·erreurs](custom-error-pages-procedure.md)
+ [Création d’une page d’erreur personnalisée pour des codes d’état HTTP spécifiques](creating-custom-error-pages.md)
+ [Stockage des objets et des pages d’erreur personnalisées dans des emplacements différents](custom-error-pages-different-locations.md)
+ [Modifier les codes de réponse renvoyés par CloudFront](custom-error-pages-response-code.md)
+ [Contrôlez la durée de mise en CloudFront cache des erreurs](custom-error-pages-expiration.md)
# Configuration du comportement de réponses aux·erreurs
Plusieurs options s'offrent à vous pour gérer le CloudFront mode de réponse en cas d'erreur. Pour configurer des réponses d'erreur personnalisées, vous pouvez utiliser la CloudFront console, l' CloudFront API ou CloudFormation. Indépendamment de la façon dont vous choisissez de mettre à jour la configuration, tenez compte des conseils et recommandations suivants :
+ Enregistrez vos pages d'erreur personnalisées dans un emplacement accessible à CloudFront. Nous vous recommandons de les stocker dans un compartiment Amazon S3 et de [ne pas les stocker dans le même emplacement que le reste du contenu de votre site Web ou de votre application](custom-error-pages-different-locations.md). Si vous stockez les pages d'erreur personnalisées sur la même origine que votre site Web ou votre application, et que l'origine commence à renvoyer des erreurs 5xx, CloudFront vous ne pouvez pas obtenir les pages d'erreur personnalisées car le serveur d'origine n'est pas disponible. Pour de plus amples informations, veuillez consulter [Stockage des objets et des pages d’erreur personnalisées dans des emplacements différents](custom-error-pages-different-locations.md).
+ Assurez-vous qu'il CloudFront est autorisé à obtenir vos pages d'erreur personnalisées. Si les pages d'erreur personnalisées sont stockées dans Amazon S3, elles doivent être accessibles au public ou vous devez configurer un [contrôle CloudFront d'accès à l'origine (OAC)](private-content-restricting-access-to-s3.md). Si les pages d'erreur personnalisées sont stockées dans une origine personnalisée, les pages doivent être accessibles publiquement.
+ (Facultatif) Configurez votre origine de sorte qu'elle ajoute un en-tête `Cache-Control` ou `Expires` avec les pages d'erreur personnalisées, si vous le souhaitez. Vous pouvez également utiliser le paramètre **TTL minimal de mise en cache des erreurs** pour contrôler la durée de mise en cache CloudFront des pages d'erreur personnalisées. Pour de plus amples informations, veuillez consulter [Contrôlez la durée de mise en CloudFront cache des erreurs](custom-error-pages-expiration.md).
## Configuration de réponses aux·erreurs personnalisées
Pour configurer des réponses d'erreur personnalisées dans la CloudFront console, vous devez disposer d'une CloudFront distribution. Dans la console, les paramètres de configuration des réponses d'erreur personnalisées ne sont disponibles que pour les distributions existantes. Pour savoir comment créer une distribution, consultez [Commencez avec une distribution CloudFront standard](GettingStarted.SimpleDistribution.md).
------
#### [ Console ]
**Pour configurer des réponses d'erreur personnalisées (console)**
1. Connectez-vous à la page **Distributions AWS Management Console et ouvrez-la** dans la CloudFront console à l'adresse[https://console.aws.amazon.com/cloudfront/v4/home#distributions](https://console.aws.amazon.com/cloudfront/v4/home#distributions).
1. Dans la liste des distributions, sélectionnez la distribution à mettre à jour.
1. Cliquez sur l'onglet **Pages d'erreur**, puis cliquez sur **Créer une réponse d'erreur personnalisée**.
1. Entrez les valeurs applicables. Pour de plus amples informations, veuillez consulter [Pages d’erreur personnalisées et mise en cache des erreurs](DownloadDistValuesErrorPages.md).
1. Après avoir saisi les valeurs souhaitées, cliquez sur **Créer**.
------
#### [ CloudFront API or CloudFormation ]
Pour configurer des réponses d'erreur personnalisées avec l' CloudFront API CloudFormation, utilisez le `CustomErrorResponse` type dans une distribution. Pour plus d’informations, consultez les ressources suivantes :
+ [AWS::CloudFront::Distribution CustomErrorResponse](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cloudfront-distribution-customerrorresponse.html) dans le *guide de l'utilisateur AWS CloudFormation *
+ [CustomErrorResponse](https://docs.aws.amazon.com/cloudfront/latest/APIReference/API_CustomErrorResponse.html)dans le *Amazon CloudFront API Reference*
------
# Création d’une page d’erreur personnalisée pour des codes d’état HTTP spécifiques
Si vous préférez afficher un message d'erreur personnalisé au lieu du message par défaut (par exemple, une page qui utilise le même format que le reste de votre site Web), vous pouvez demander à l'utilisateur de CloudFront renvoyer un objet (tel qu'un fichier HTML) contenant votre message d'erreur personnalisé.
Pour spécifier le fichier que vous souhaitez renvoyer et les erreurs pour lesquelles le fichier doit être renvoyé, vous mettez à jour votre CloudFront distribution pour spécifier ces valeurs. Pour de plus amples informations, veuillez consulter [Configuration du comportement de réponses aux·erreurs](custom-error-pages-procedure.md).
Par exemple, voici une page d'erreur personnalisée :
![\[Capture d'écran d'un exemple de page AWS 404 personnalisée.\]](http://docs.aws.amazon.com/fr_fr/AmazonCloudFront/latest/DeveloperGuide/images/custom-error-page-aws-404-example.png)
Vous pouvez spécifier un objet différent pour chaque code de statut HTTP pris en charge, ou utiliser le même objet pour tous les codes de statut pris en charge. Vous pouvez choisir de spécifier des pages d'erreur personnalisées pour certains codes d'état et pas d'autres.
Les objets que vous servez CloudFront peuvent être indisponibles pour diverses raisons. Ces raisons se divisent en deux grandes catégories :
+ Les *erreurs client* indiquent un problème lié à la demande. Par exemple, un objet portant le nom spécifié n'est pas disponible, ou l'utilisateur ne dispose pas des autorisations requises pour obtenir un objet dans votre compartiment Amazon S3. Lorsqu'une erreur client se produit, l'origine renvoie un code d'état HTTP compris entre 4xx et. CloudFront
+ Les *erreurs serveur* indiquent un problème lié au serveur d'origine. Par exemple, le serveur HTTP est occupé ou indisponible. Lorsqu'une erreur de serveur se produit, soit votre serveur d'origine renvoie un code d'état HTTP de l'ordre de 5xx à CloudFront, soit CloudFront il ne reçoit pas de réponse de votre serveur d'origine pendant un certain temps et suppose un code d'état 504 (Gateway Timeout).
Les codes d'état HTTP pour lesquels une page d'erreur personnalisée CloudFront peut être renvoyée sont les suivants :
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
**Remarques**
S'il CloudFront détecte que la demande n'est peut-être pas sûre, CloudFront renvoie une erreur 400 (mauvaise demande) au lieu d'une page d'erreur personnalisée.
Vous pouvez créer une page d'erreur personnalisée pour le code d'état HTTP 416 (plage demandée non satisfaisante), et vous pouvez modifier le code d'état HTTP qui est CloudFront renvoyé aux utilisateurs lorsque votre origine renvoie un code d'état 416 à CloudFront. Pour de plus amples informations, veuillez consulter [Modifier les codes de réponse renvoyés par CloudFront](custom-error-pages-response-code.md). Cependant, CloudFront ne met pas en cache les réponses du code d'état 416, donc même si vous spécifiez une valeur pour **Error Caching Minimum TTL** pour le code d'état 416, CloudFront il ne l'utilise pas.
Dans certains cas, CloudFront ne renvoie pas de page d'erreur personnalisée pour le code d'état HTTP 503, même si vous le configurez CloudFront à cet effet. Si le code CloudFront d'erreur est `Capacity Exceeded` ou`Limit Exceeded`, CloudFront renvoie un code d'état 503 au lecteur sans utiliser votre page d'erreur personnalisée.
Si vous avez créé une page d'erreur personnalisée, elle CloudFront sera renvoyée `Connection: close` ou `Connection: keep-alive` pour les codes de réponse suivants :
CloudFront retours `Connection: close` pour les codes d'état : 400, 405, 414, 416, 500, 501
CloudFront retours `Connection: keep-alive` pour les codes d'état : 403, 404, 502, 503, 504
Pour une explication détaillée de la gestion CloudFront des réponses d'erreur provenant de votre origine, consultez[Comment CloudFront traite les codes d'état HTTP 4xx et 5xx de votre origine](HTTPStatusCodes.md).
# Stockage des objets et des pages d’erreur personnalisées dans des emplacements différents
Si vous souhaitez stocker vos objets et vos pages d’erreur personnalisées dans des emplacements différents, votre distribution doit inclure un comportement de cache pour lequel les conditions suivantes sont vraies :
+ La valeur de **Modèle de chemin** correspond au chemin d’accès de vos messages d’erreur personnalisés. Par exemple, supposons que vous ayez enregistré des pages d’erreur personnalisées pour les erreurs 4xx dans un compartiment Amazon S3 d’un répertoire nommé `/4xx-errors`. Votre distribution doit inclure un comportement de cache pour lequel le modèle de chemin transmet les demandes de vos pages d'erreur personnalisées vers cet emplacement (par exemple,, `/4xx-errors/*`.
+ La valeur d’**Origine** spécifie la valeur d’**ID d’origine** pour l’origine qui contient vos pages d’erreur personnalisées.
Pour de plus amples informations, veuillez consulter [Paramètres de comportement du cache](DownloadDistValuesCacheBehavior.md).
# Modifier les codes de réponse renvoyés par CloudFront
Vous pouvez configurer CloudFront pour renvoyer au lecteur un code d'état HTTP différent de celui CloudFront reçu de l'origine. Par exemple, si votre origine renvoie un code d'état 500 àCloudFront, vous souhaiterez peut-être CloudFront renvoyer une page d'erreur personnalisée et un code d'état 200 (OK) au lecteur. Il existe plusieurs raisons pour lesquelles vous souhaiterez peut-être CloudFront renvoyer au spectateur un code de statut différent de celui renvoyé par votre source d'origine CloudFront :
+ Certains dispositifs Internet (certains pare-feu et proxys d'entreprise, par exemple) interceptent les codes d'état HTTP 4xx et 5xx, et empêchent le renvoi d'une réponse à l'utilisateur. Dans ce cas, si vous remplacez `200`, la réponse n'est pas interceptée.
+ Si vous ne vous souciez pas de faire la distinction entre les différentes erreurs client ou serveur, vous pouvez spécifier `400` ou `500` comme valeur CloudFront renvoyée pour tous les codes d'état 4xx ou 5xx.
+ Vous pouvez décider de renvoyer un code d'état `200` (OK) et un site Web statique pour que vos clients ne sachent pas que votre site Web est en panne.
Si vous activez [les journaux CloudFront standard](AccessLogs.md) et que vous configurez CloudFront pour modifier le code d'état HTTP dans la réponse, la valeur de la `sc-status` colonne des journaux contient le code d'état que vous spécifiez. Cela n'affecte pas la valeur de la colonne `x-edge-result-type`. Elle contient le type de résultat de la réponse de l'origine. Supposons, par exemple, que vous configuriez CloudFront pour renvoyer un code d'état de `200` au visualiseur lorsque l'origine renvoie `404` (Non trouvé) à CloudFront. Lorsque l'origine répond à une demande avec un code d'état `404`, la valeur de la colonne `sc-status` dans le journal sera `200`, mais la valeur de la colonne `x-edge-result-type` sera `Error`.
Vous pouvez configurer CloudFront pour renvoyer l'un des codes d'état HTTP suivants ainsi qu'une page d'erreur personnalisée :
+ 200
+ 400, 403, 404, 405, 414, 416
+ 500, 501, 502, 503, 504
# Contrôlez la durée de mise en CloudFront cache des erreurs
CloudFront met en cache les réponses aux erreurs pendant une durée par défaut de 10 secondes. CloudFront soumet ensuite la demande suivante pour l'objet à votre origine pour voir si le problème à l'origine de l'erreur a été résolu et si l'objet demandé est disponible.
Vous pouvez spécifier la durée de mise en cache des erreurs (**TTL minimum de mise en cache des erreurs) pour chaque code d'état 4xx et 5xx** mis en cache. CloudFront (Pour plus d’informations, consultez [Codes d'état HTTP 4xx et 5xx mis en cache CloudFront](HTTPStatusCodes.md#HTTPStatusCodes-cached-errors).) Lorsque vous spécifiez une durée, veuillez noter les points suivants :
+ Si vous spécifiez une courte durée de mise en cache des erreurs, CloudFront vous transmettez plus de demandes à votre origine que si vous spécifiez une durée plus longue. Pour les erreurs 5xx, cela peut aggraver le problème qui a initialement amené votre origine à renvoyer une erreur.
+ Lorsque votre origine renvoie une erreur pour un objet, elle CloudFront répond aux demandes concernant l'objet soit par la réponse d'erreur, soit par votre page d'erreur personnalisée jusqu'à ce que la durée de mise en cache des erreurs soit écoulée. Si vous spécifiez une longue durée de mise en cache des erreurs, vous CloudFront pouvez continuer à répondre aux demandes avec une réponse d'erreur ou votre page d'erreur personnalisée pendant une longue période une fois que l'objet sera de nouveau disponible.
**Note**
Vous pouvez créer une page d'erreur personnalisée pour le code de statut HTTP 416 (Plage demandée impossible à respecter), et vous pouvez modifier le code de statut HTTP que CloudFront renvoie aux utilisateurs quand votre origine retourne un code de statut 416 à CloudFront. (Pour plus d’informations, consultez [Modifier les codes de réponse renvoyés par CloudFront](custom-error-pages-response-code.md).) Cependant, CloudFront ne met pas en cache les réponses du code d'état 416, donc même si vous spécifiez une valeur pour **Error Caching Minimum TTL** pour le code d'état 416, CloudFront il ne l'utilise pas.
Si vous souhaitez contrôler la durée de mise en CloudFront cache des erreurs pour des objets individuels, vous pouvez configurer votre serveur d'origine pour ajouter l'en-tête applicable à la réponse d'erreur pour cet objet.
Si l'origine ajoute une `Cache-Control: s-maxage` directive `Cache-Control: max-age` ou, ou un `Expires` en-tête, met en CloudFront cache les réponses d'erreur pour la valeur la plus élevée entre la valeur de l'en-tête ou le TTL **minimal de mise en cache des erreurs**.
**Note**
Les valeurs `Cache-Control: max-age` et `Cache-Control: s-maxage` ne peuvent pas être supérieures à la valeur de **Maximum TTL** (Durée de vie maximale) définie pour le comportement de cache pour lequel la page d'erreur est récupérée.
Si l'origine ajoute une `Cache-Control: private` directive `Cache-Control: no-store``Cache-Control: no-cache`, ou pour les codes d'erreur 404, 410, 414 ou 501, la réponse d'erreur CloudFront ne sera pas mise en cache. Pour tous les autres codes d'erreur, CloudFront ignore les `private` directives `no-store``no-cache`, et met en cache la réponse d'erreur correspondant à la valeur du TTL minimal de **mise en cache d'erreur**.
Si l'origine ajoute d'autres `Cache-Control` directives ou n'ajoute aucun en-tête, CloudFront met en cache les réponses d'erreur pour la valeur de Error **Caching Minimum** TTL.
Si le délai d'expiration d'un code d'état 4xx ou 5xx pour un objet est supérieur à votre attente, et que l'objet est à nouveau disponible, vous pouvez invalider le code de l'erreur mise en cache à l'aide de l'URL de l'objet demandé. Si votre origine renvoie une réponse d'erreur pour plusieurs objets, vous devez invalider chaque objet séparément. Pour en savoir plus sur l'invalidation d'objets, consultez [Invalidation de fichiers pour supprimer du contenu](Invalidation.md).
Si la mise en cache est activée pour l'origine d'un compartiment S3 et que vous configurez un TTL de mise en cache d'erreur de 0 seconde dans votre CloudFront distribution, vous verrez toujours un TTL de mise en cache d'une seconde pour les erreurs d'origine S3. CloudFront fait cela pour protéger votre origine des attaques DDo S. Cette règle ne concerne pas les autres types d’origines.