Comment CloudFront traite et met en cache les codes d'état HTTP 4xx et 5xx depuis 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 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.

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.

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 toujours mis en cache CloudFront.

  • L’origine renvoie un code de statut HTTP 4xx sans en-tête Cache-Control max-age ou sans en-tête Cache-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 :

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.

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

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

4. L’origine renvoie la page d’erreur personnalisée à l’emplacement périphérique.

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

6. 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 :

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.

2. 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, consultezGestion de la durée de conservation de contenu dans le cache périphérique (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 toujours mis en cache CloudFront

  • L’origine renvoie un code de statut HTTP 4xx sans en-tête Cache-Control max-age ou sans en-tête Cache-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 :

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

2. Pendant la durée de la mise en cache (déterminée à l'étape 1), CloudFront répond aux demandes ultérieures du spectateur pour le même objet avec le code d'état 4xx ou 5xx mis en cache.

3. 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 :

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.

2. 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, consultezGestion de la durée de conservation de contenu dans le cache périphérique (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.

Codes d'état HTTP 4xx et 5xx toujours mis en cache CloudFront

CloudFront met toujours en cache les codes d'état 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.

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