Les équilibreurs de charge d'application externes globaux vous permettent de personnaliser vos propres réponses d'erreur lorsqu'un code d'état d'erreur HTTP (4xx et 5xx) est généré. Vous pouvez personnaliser les réponses d'erreur pour les erreurs générées par l'équilibreur de charge et les instances backend. Vous pouvez également personnaliser les réponses d'erreur pour les codes de réponse d'erreur générés lorsque le trafic est refusé par Google Cloud Armor.
Voici un exemple de page d'erreur personnalisée sur laquelle vous pouvez configurer des réponses d'erreur pour votre application grand public externe avec la marque et le logo de votre entreprise, des liens vers des pages associées et un message personnalisé.
En utilisant une stratégie de réponse d'erreur personnalisée, vous pouvez configurer différentes réponses d'erreur pour différents codes d'état d'erreur HTTP, domaines d'URL, chemins d'URL, et champs d'en-tête et de paramètres de requête HTTP.
Le renvoi de réponses d'erreur personnalisées vous permet d'améliorer l'expérience de vos utilisateurs en offrant les avantages suivants :
- Offre une expérience de branding cohérente
- Fournit des informations contextuelles et pertinentes pour améliorer la facilité d'utilisation et l'expérience utilisateur
- Atténue l'impact négatif des temps d'arrêt et des erreurs côté client
- Améliore la sécurité du réseau
Si vous ne configurez pas de stratégie de réponse d'erreur personnalisée, un objet d'erreur générique non associé à une marque est diffusé, comme illustré dans la figure 2.
Cas d'utilisation
La fonctionnalité de réponse d'erreur personnalisée répond à de nombreux cas d'utilisation. Cette section fournit quelques exemples généraux.
Définir votre propre page de maintenance
Vous pouvez renvoyer une page d'erreur avec le branding et les informations de l'entreprise lorsque vos backends ne sont pas opérationnels ou sont en mode maintenance. Vous pouvez créer des pages d'erreur contextuelles contenant des informations utiles telles que les numéros de téléphone d'un centre d'appels ou dans les cas où les utilisateurs doivent réessayer d'accéder au site Web. Vous avez la possibilité de personnaliser les pages d'erreur en fonction de la correspondance de conditions d'erreur telles que le nom d'hôte et le code d'erreur HTTP.
Définir votre propre page d'erreur par défaut
Vous pouvez configurer des réponses d'erreur personnalisées en fonction de codes d'erreur spécifiques. Par exemple, vous pouvez configurer une page d'erreur avec un message "Se connecter ou s'enregistrer" pour un code de réponse HTTP 401 (Unauthorized). Vous pouvez également configurer une page d'erreur par défaut contenant le branding de l'entreprise et d'autres informations pertinentes pour tous les autres codes d'erreur HTTP des séries 4xx et 5xx.
Définir des réponses d'erreur pour les règles de sécurité
Vous pouvez renvoyer une page d'erreur personnalisée pour les codes de réponse d'erreur générés lorsque le trafic est refusé par les stratégies de sécurité Google Cloud Armor. Vous devez vous assurer de configurer la page d'erreur avec le même code d'erreur HTTP de la série 4xx ou de la série 5xx que celui saisi dans la règle de sécurité Google Cloud Armor.
Atténuer l'impact des temps d'arrêt
Le cas échéant, vous pouvez configurer une réponse d'erreur pour renvoyer un code d'état HTTP 200 (OK) et diffuser une page Web statique afin que les utilisateurs aient accès à des informations plus contextuelles et utiles au lieu d'une page d'erreur pendant le temps d'arrêt.
Personnaliser les réponses d'erreur en fonction du type de requête client
Vous pouvez personnaliser une réponse d'erreur en fonction des en-têtes et des paramètres de requête HTTP, par exemple l'en-tête Content-Type. Lors du routage de la requête d'origine vers le service d'erreur, le routage peut prendre en compte l'en-tête Content-Type pour diffuser une page Web (pour les requêtes des navigateurs) ou JSON (pour les requêtes provenant d'une API Web).
Fonctionnement des règles de réponse d'erreur personnalisées
Une stratégie de réponse d'erreur personnalisée peut être définie à trois niveaux de la ressource de mappage d'URL : au niveau de l'équilibreur de charge, au niveau du domaine de l'URL et au niveau du chemin de l'URL.
Niveau de l'équilibreur de charge. La règle est appliquée à tout le trafic reçu par l'équilibreur de charge.
Niveau du domaine de l'URL. La règle s'applique au trafic dirigé vers un nom de domaine ou un nom d'hôte spécifique, par exemple
www.example.com.Niveau du chemin de l'URL. La stratégie est appliquée au trafic dirigé vers un chemin spécifique (par exemple,
www.example.com/images/*). À ce niveau, vous pouvez également utiliser des conditions de correspondance avancées avec des en-têtes et des paramètres de requête HTTP, par exempleContent-Type:application/json.
Le tableau suivant présente une stratégie de réponse d'erreur personnalisée appliquée au niveau de l'équilibreur de charge, au niveau du domaine de l'URL et au niveau du chemin d'URL du mappage d'URL.
| Niveau de la règle | Champ de l'API |
|---|---|
| Équilibreur de charge | urlMaps.defaultCustomErrorResponsePolicy |
| URL du domaine | pathMatchers[].defaultCustomErrorResponsePolicy |
| Chemin de l'URL |
|
Si vous configurez une stratégie de réponse d'erreur personnalisée à plusieurs niveaux de la ressource de mappage d'URL, l'objet d'erreur spécifié par la stratégie d'erreur personnalisée au niveau le plus bas du mappage d'URL est renvoyé. Les stratégies de réponse d'erreur définies à un niveau inférieur du mappage d'URL sont plus spécifiques et prévalent sur les stratégies de réponse d'erreur définies à un niveau supérieur du mappage d'URL.
Par exemple, une stratégie de réponse d'erreur personnalisée au niveau de l'équilibreur de charge n'est appliquée que si elle remplit les conditions d'erreur et qu'aucune règle de correspondance n'a été définie pour le code d'erreur aux niveaux inférieurs (domaine de l'URL ou chemin de l'URL). De même, une stratégie de réponse d'erreur personnalisée au niveau du domaine de l'URL n'est appliquée que si elle remplit les conditions d'erreur et qu'aucune règle de correspondance n'a été définie pour le code d'erreur au niveau inférieur (le chemin de l'URL). Pour en savoir plus sur cette configuration, consultez Configurer des stratégies de réponse d'erreur personnalisées précises pour différents domaines, chemins et codes de réponse d'erreur.
Spécifier plusieurs règles de réponse d'erreur pour correspondre aux codes de réponse d'erreur HTTP
À n'importe quel niveau d'une stratégie de réponse d'erreur personnalisée, vous pouvez spécifier plusieurs règles de réponse d'erreur. Ces règles peuvent mettre en correspondance une réponse d'erreur HTTP avec des codes d'erreur spécifiques ou une plage de codes d'erreur. Si vous spécifiez une règle pour une plage de codes d'erreur ainsi que des règles pour des codes d'erreur spécifiques, les règles avec des codes d'erreur spécifiques prévalent.
Par exemple, supposons que vous configuriez une règle pour un code d'erreur 401 (Unauthorized) et une autre règle pour tous les codes d'erreur de la série 4xx. Si le service de backend renvoie un code d'erreur 401, la règle correspondant à l'erreur 401 est appliquée. Toutefois, si le service de backend renvoie un code d'erreur 403, la règle concernant les erreurs 4xx prend effet.
Remplacer le code de réponse HTTP
Les règles de réponse d'erreur vous permettent de modifier le code de réponse HTTP renvoyé par l'équilibreur de charge. Cela signifie essentiellement que vous pouvez remplacer le code de réponse généré par le serveur et définir le code de réponse final de la requête. Vous pouvez spécifier de renvoyer n'importe quel code de réponse HTTP, y compris 200 (OK), la série 4xx ou la série 5xx de codes de réponse, ou tout autre code de réponse à trois chiffres. Pour en savoir plus sur le remplacement du code de réponse, consultez la section Configurer une page d'erreur pour un code d'erreur spécifique pour un hôte spécifique.
Si vous définissez un code de réponse de remplacement, il est capturé en tant que nouveau champ overrideResponseCodeServed dans les journaux d'équilibrage de charge. Ce champ n'est renseigné que pour les requêtes pour lesquelles un code de réponse de remplacement est appliqué par la règle de réponse d'erreur personnalisée.
Le code status consigné dans le champ httpRequest n'est pas affecté.
Il capture le code de réponse HTTP généré par le serveur ou la réponse HTTP renvoyée par l'équilibreur de charge. Ce code d'état peut être différent du code réel envoyé au client si le code de réponse est modifié par une règle de réponse d'erreur personnalisée.
Mettre en cache les réponses d'erreur personnalisées
Une réponse d'erreur personnalisée peut être mise en cache en spécifiant une stratégie de mise en cache négative pour le backend qui a généré l'erreur, afin d'appliquer un contrôle précis sur la mise en cache des erreurs ou des redirections courantes. Ce processus peut réduire la charge pesant sur vos origines et améliorer l'expérience de l'utilisateur final en réduisant la latence des réponses.
Une règle de mise en cache négative définie pour le backend qui a généré l'erreur a toujours la priorité sur les métadonnées Cache-Control définies pour l'objet d'erreur dans le service d'erreur. De plus, si un code de réponse de forçage est renvoyé par l'équilibreur de charge, une stratégie de mise en cache négative est appliquée en fonction de la valeur du code de réponse de forçage et non du code de réponse d'origine renvoyé par le backend à l'équilibreur de charge. Si un code autre qu'un code d'erreur (HTTP 200) est renvoyé en tant que code de réponse de remplacement, aucune stratégie de mise en cache négative ne s'applique.
Si la valeur TTL (Time To Live) de la réponse d'erreur n'a pas expiré, l'équilibreur de charge continue de diffuser le contenu mis en cache sans acheminer la requête vers un service de backend ou un bucket backend. Toutefois, ce comportement dépend de l'activation ou non de Cloud CDN pour votre équilibreur de charge.
Cloud CDN est activé pour l'équilibreur de charge
Cette section décrit le comportement de l'équilibreur de charge lorsque Cloud CDN est activé et que des réponses d'erreur personnalisées sont utilisées.
Lorsqu'une requête est reçue par l'équilibreur de charge, il vérifie le cache Cloud CDN. Si l'équilibreur de charge trouve une réponse mise en cache à la requête de l'utilisateur, il renvoie la réponse mise en cache à l'utilisateur. Cette réponse mise en cache peut être le contenu demandé par l'utilisateur ou un objet d'erreur personnalisé.
En cas de défaut de cache (miss), la requête est traitée par l'équilibreur de charge et envoyée au backend.
Si le backend renvoie une réponse sans erreur, cette réponse est renvoyée à l'utilisateur final. Toutefois, si une requête client rencontre une erreur (un code de réponse HTTP
4xxou5xx), l'équilibreur de charge tente d'obtenir l'objet d'erreur personnalisé à partir du service d'erreur que vous avez spécifié de la manière suivante :L'équilibreur de charge vérifie toutes les stratégies de réponse d'erreur personnalisées et obtient le chemin approprié de l'objet d'erreur personnalisée qui correspond au code d'état de l'erreur et aux autres conditions de correspondance.
L'équilibreur de charge transfère la requête de l'objet d'erreur personnalisée au service d'erreur que vous avez spécifié dans la stratégie de réponse d'erreur personnalisée. Le terme service d'erreur fait référence au bucket backend ou au service de backend qui diffuse le contenu d'erreur personnalisé.
L'équilibreur de charge renvoie l'objet d'erreur personnalisé au client à l'origine de la requête. Il envoie également l'objet à Cloud CDN pour mettre en cache l'objet d'erreur pendant la durée spécifiée par
cdnPolicy.negativeCachingPolicy[].ttl.
Cloud CDN est désactivé pour l'équilibreur de charge
Si Cloud CDN est désactivé, nous vous recommandons d'utiliser un bucket backend comme service d'erreur et non un service de backend. En effet, un service de backend ne peut pas mettre en cache du contenu si Cloud CDN est désactivé. Toutefois, les buckets backend disposent d'une fonctionnalité de mise en cache intégrée et peuvent mettre en cache des réponses d'erreur, même si Cloud CDN est désactivé.
Limites
Les réponses d'erreur personnalisées ne sont compatibles qu'avec l'équilibreur de charge d'application externe global. Les modes régional et classique ne sont pas compatibles.
Si l'objet d'erreur personnalisé ne peut pas être récupéré à partir du service d'erreur (par exemple, si le chemin d'accès au contenu est mal configuré), un objet d'erreur générique non associé à une marque est diffusé.
La règle de réponse aux erreurs personnalisées ne surveille ni ne filtre l'objet renvoyé par le service d'erreur pour détecter les risques de sécurité. Par conséquent, vous devez être diligent pour éliminer les failles et limiter l'impact d'une exposition potentielle.
Les réponses d'erreur personnalisées ne sont compatibles qu'avec les buckets Cloud Storage lisibles publiquement.
Pour éviter toute erreur de configuration lors de l'utilisation d'un bucket Cloud Storage, consultez les bonnes pratiques courantes relatives à Cloud Storage.
Les réponses d'erreur personnalisées ne fonctionnent pas si votre équilibreur de charge d'application externe global ne comporte que des buckets backend. Vous devez également disposer d'au moins un service de backend associé à l'équilibreur de charge, en plus du bucket backend.
Les en-têtes de réponse personnalisés définis en fonction de la source de la réponse d'erreur personnalisée ne sont pas appliqués aux réponses sortantes.
Tarifs
L'utilisation de réponses d'erreur personnalisées n'entraîne aucun coût supplémentaire. La tarification standard pour l'équilibrage de charge Google Cloud s'applique. Pour en savoir plus, reportez-vous à la section Tarification.