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.
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 de statut
-
Pour les codes d'état 5xx, si l'objet demandé se trouve actuellement dans le cache CloudFront périphérique
-
Pour certains codes de statut 4xx, si l'origine renvoie un
Cache-Control max-ageou un en-têteCache-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.
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, consultezPages d’erreur personnalisées et mise en cache des erreurs.
-
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)
-
Pour obtenir la liste des codes d'état HTTP mis en CloudFront cache, consultezCodes d'état HTTP 4xx et 5xx mis en cache CloudFront .
Rubriques
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 .
-
L’origine renvoie un code de statut HTTP 4xx sans en-tête
Cache-Control max-ageou sans en-têteCache-Control s-maxage, et le code de statut est inclus dans la liste suivante de codes de statut : Control Codes d'état HTTP 4xx mis en CloudFront cache en fonction des en-têtes Cache-Control.
-
CloudFront effectue les opérations suivantes :
-
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.
-
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.
-
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.
-
L’origine renvoie la page d’erreur personnalisée à l’emplacement périphérique.
-
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-ageou un en-têteCache-Control s-maxagequi est renvoyé par l’origine lorsque la première demande a généré l’erreur
-
-
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.
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 :
-
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.
-
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, consultezGérer la durée pendant laquelle le contenu reste dans le cache (expiration).
Comment CloudFront traite les erreurs lorsque 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.
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
-
L’origine renvoie un code de statut HTTP 4xx sans en-tête
Cache-Control max-ageou sans en-têteCache-Control s-maxage, et le code de statut est inclus dans la liste suivante de codes de statut : Control Codes d'état HTTP 4xx mis en CloudFront cache en fonction des en-têtes Cache-Control.
-
CloudFront effectue les opérations suivantes :
-
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-ageou un en-têteCache-Control s-maxagequi est renvoyé par l’origine lorsque la première demande a généré l’erreur
-
-
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.
-
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é
-
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 :
-
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.
-
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, consultezGérer la durée pendant laquelle le contenu reste dans le cache (expiration).
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 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 ouCache-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.
