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