Los balanceadores de cargas de aplicaciones externos globales te permiten personalizar tus propias respuestas de error cuando se genera un código de estado de error de HTTP (4xx y 5xx). Puedes personalizar las respuestas de error para los errores que generan el
balanceador de cargas y las instancias de backend. También puedes personalizar las respuestas de error para los códigos de respuesta de error que se generan cuando Google Cloud Armor rechaza el tráfico.
Este es un ejemplo de una página de error personalizada en la que puedes configurar respuestas de error para tu aplicación para consumidores orientada al exterior con tu propio desarrollo de la marca y logotipo de la empresa, vínculos a páginas relacionadas y mensajes personalizados.
Mediante una política de respuesta de error personalizada, puedes configurar diferentes respuestas de error para diferentes códigos de estado de error de HTTP, dominios de URL, rutas de URL y campos de parámetros y encabezados de solicitud HTTP.
Devolver respuestas de error personalizadas te ayuda a mejorar la experiencia de los usuarios, ya que ofrece los siguientes beneficios:
- Proporciona una experiencia de desarrollo de la marca coherente
- Proporciona información contextual y relevante para mejorar la usabilidad y la experiencia del usuario.
- Mitiga el impacto negativo del tiempo de inactividad y los errores del cliente
- Mejora la seguridad de la red
Si no configuras una política de respuesta de error personalizada, se entrega un objeto de error genérico sin marca, como se muestra en la figura 2.
Casos de uso
La función de respuesta de error personalizada aborda muchos casos de uso. En esta sección, se proporcionan algunos ejemplos de alto nivel.
Define tu propia página de mantenimiento
Puedes mostrar una página de error con el desarrollo de la marca y la información de la empresa cuando tus backends están en mal estado o en modo de mantenimiento. Puedes crear páginas de error contextuales que contengan información útil, como números de teléfono del centro de contacto o cuándo los usuarios deben volver a intentar acceder al sitio web. Tienes la opción de personalizar las páginas de error según la coincidencia de las condiciones de error, como el nombre de host y el código de error de HTTP.
Define tu propia página de error predeterminada
Puedes configurar respuestas de error personalizadas por códigos de error específicos. Por ejemplo, puedes configurar una página de error con un mensaje "Acceder o registrarse" para un código de respuesta HTTP 401 (Unauthorized). También puedes configurar una página de error predeterminada que contenga la marca de la empresa y otra información relevante para todas las demás series 4xx y códigos de error de HTTP de las series 5xx.
Define respuestas de error para las reglas de seguridad
Puedes mostrar una página de error personalizada para los códigos de respuesta de error que se generan cuando las políticas de seguridad de Google Cloud Armor rechazan el tráfico. Debes asegurarte de configurar la página de error con el mismo código de error de HTTP de la serie 4xx o de la serie 5xx que ingresaste en la regla de seguridad de Google Cloud Armor.
Mitiga el impacto del tiempo de inactividad
Cuando corresponda, puedes configurar una respuesta de error para que muestre un código de estado HTTP 200 (OK) y entregue una página web estática para que los usuarios vean información más contextual y útil en lugar de una página de error durante el tiempo de inactividad.
Personaliza las respuestas de error según el tipo de solicitud del cliente
Puedes personalizar una respuesta de error según los encabezados y parámetros de la solicitud HTTP, por ejemplo, el encabezado Content-Type. Cuando se enruta la solicitud original al servicio de errores, el enrutamiento puede tener en cuenta el encabezado Content-Type para entregar una página web (para solicitudes de navegadores) o JSON (para solicitudes de una API web).
Cómo funcionan las políticas de respuesta de error personalizadas
Se puede definir una política de respuesta de error personalizada en tres niveles del recurso de mapa de URL: el nivel del balanceador de cargas, el nivel del dominio de la URL y el nivel de la ruta de URL.
Nivel del balanceador de cargas. La política se aplica a todo el tráfico que recibe el balanceador de cargas.
Nivel de dominio de la URL. La política se aplica al tráfico dirigido a un nombre de dominio o un nombre de host específico, por ejemplo,
www.example.com.Nivel de ruta de URL. La política se aplica al tráfico dirigido a una ruta específica, por ejemplo,
www.example.com/images/*. En este nivel, también puedes usar condiciones de coincidencia avanzadas con encabezados y parámetros de solicitud HTTP, por ejemplo,Content-Type:application/json.
En la siguiente tabla, se muestra una política de respuesta de error personalizada que se aplica a nivel del balanceador de cargas, del dominio de la URL y de la ruta de URL del mapa de URLs.
| Nivel de la política | Campo de API |
|---|---|
| Balanceador de cargas | urlMaps.defaultCustomErrorResponsePolicy |
| Dominio de URL | pathMatchers[].defaultCustomErrorResponsePolicy |
| Ruta de URL |
|
Si configuras una política de respuesta de error personalizada en varios niveles del recurso del mapa de URL, se muestra el objeto de error especificado por la política de error personalizada en el nivel más bajo del mapa de URL. Las políticas de respuesta de error definidas en un nivel inferior del mapa de URL son más específicas y tienen prioridad sobre las políticas de respuesta de error definidas en un nivel superior del mapa de URL.
Por ejemplo, una política de respuesta de error personalizada en el nivel del balanceador de cargas se aplica solo si la política coincide con las condiciones de error y no se definió ninguna política coincidente para el código de error en los niveles inferiores: el dominio de URL o ruta de URL. Del mismo modo, una política de respuesta de error personalizada en el nivel del dominio de URL se aplica solo si la política coincide con las condiciones de error y no se definió ninguna política coincidente para el código de error en el nivel inferior; es decir, la ruta de URL. Para obtener más información sobre esta configuración, consulta Configura políticas de respuesta de error personalizadas detalladas para diferentes dominios, rutas y códigos de respuesta de error.
Especifica varias reglas de respuesta de error para que coincidan con los códigos de respuesta de error de HTTP
En cualquier nivel de una política de respuesta de error personalizada, puedes especificar varias reglas de respuesta de error. Estas reglas pueden hacer coincidir una respuesta de error de HTTP con códigos de error específicos o un rango de códigos de error. Si especificas una regla para un rango de códigos de error, así como reglas para códigos de error específicos, las reglas con códigos de error específicos tienen prioridad.
Por ejemplo, supongamos que configuras una regla para un código de error 401 (Unauthorized) y otra regla para todos los códigos de error de la serie 4xx. Si el servicio de backend muestra un código de error 401, se aplica la regla que coincide con el error 401. Sin embargo, si el servicio de backend muestra un código de error 403, se aplica la regla para los errores 4xx.
Anula el código de respuesta HTTP
Las reglas de respuesta de error te permiten modificar el código de respuesta HTTP que muestra el balanceador de cargas. Esto significa que puedes anular el código de respuesta que genera el servidor y definir cuál debe ser el código de respuesta final para la solicitud. Puedes especificar que se muestre cualquier código de respuesta HTTP, incluido 200 (OK), la serie 4xx o la serie 5xx de códigos de respuesta, o cualquier otro código de respuesta de tres dígitos. Para obtener más información sobre cómo anular el código de respuesta, consulta Cómo configurar una página de error para un código de error específico de un host específico.
Si defines un código de respuesta de anulación, se captura como un campo nuevo overrideResponseCodeServed en los registros de balanceo de cargas. Este campo solo se propaga para aquellas solicitudes en las que la política de respuesta de error personalizada aplica un código de respuesta de anulación.
El código status registrado en el campo httpRequest no se ve afectado.
Captura el código de respuesta HTTP que genera el servidor o la respuesta HTTP que muestra el balanceador de cargas. Este código de estado puede ser diferente del código real que se entrega al cliente si el código de respuesta se modifica con una política de respuesta de error personalizada.
Cómo almacenar en caché respuestas de errores personalizadas
Para almacenar en caché una respuesta de error personalizada, especifica una política de almacenamiento en caché negativa para el backend que generó el error. El propósito de esto es aplicar un control detallado sobre el almacenamiento en caché para redireccionamientos o errores comunes. Esto puede reducir la carga en los orígenes y mejorar la experiencia del usuario final mediante la reducción de la latencia de respuesta.
Una política de almacenamiento en caché negativa definida para el backend que generó el error siempre tiene prioridad sobre los metadatos Cache-Control definidos para el objeto de error en el servicio de error. Además, si el balanceador de cargas muestra un código de respuesta de anulación, se aplica una política de almacenamiento en caché negativo en función del valor del código de respuesta de anulación y no según el código de respuesta original que el backend devolvió al balanceador de cargas. Si se muestra un código que no es de error (HTTP 200) como un código de respuesta de anulación, no se aplica una política de almacenamiento en caché negativa.
Si el tiempo de actividad (TTL) de la respuesta de error no venció, el balanceador de cargas sigue entregando contenido almacenado en caché sin enrutar la solicitud a un servicio de backend o un bucket de backend. Sin embargo, este comportamiento depende de si Cloud CDN está habilitado para el balanceador de cargas.
Cloud CDN está habilitado para el balanceador de cargas
En esta sección, se describe el comportamiento del balanceador de cargas cuando Cloud CDN está habilitado y se usan respuestas de error personalizadas.
Cuando el balanceador de cargas recibe una solicitud, verifica la caché de Cloud CDN. Si el balanceador de cargas encuentra una respuesta almacenada en caché para la solicitud del usuario, el balanceador de cargas muestra la respuesta almacenada en caché al usuario. Esta respuesta almacenada en caché puede ser el contenido solicitado por el usuario o un objeto de error personalizado.
Si no se encuentra en la caché, el balanceador de cargas procesa la solicitud y la envía al backend.
Si el backend entrega una respuesta sin errores, esa respuesta se muestra al usuario final. Sin embargo, si una solicitud del cliente encuentra un error (un código de respuesta HTTP
4xxo5xx), el balanceador de cargas intenta obtener el objeto de error personalizado del servicio de error que especificaste de la siguiente manera:El balanceador de cargas verifica todas las políticas de respuesta de error personalizadas y obtiene la ruta de acceso adecuada del objeto de error personalizado que corresponde al código de estado de error y a otras condiciones de coincidencia.
El balanceador de cargas reenvía la solicitud del objeto de error personalizado al servicio de error que especificaste en la política de respuesta de error personalizada. El término servicio de error hace referencia al bucket de backend o al servicio de backend que entrega el contenido del error personalizado.
El balanceador de cargas devuelve el objeto de error personalizado al cliente que realizó la solicitud. También envía el objeto a Cloud CDN para almacenar en caché el objeto de error durante el tiempo especificado por
cdnPolicy.negativeCachingPolicy[].ttl.
Cloud CDN está inhabilitado para el balanceador de cargas
Si Cloud CDN está inhabilitado, recomendamos el uso de un bucket de backend como servicio de error y no un servicio de backend. Esto se debe a que un servicio de backend no puede almacenar contenido en caché si Cloud CDN está inhabilitado. Sin embargo, los buckets de backend tienen capacidad de almacenamiento en caché integrada y pueden almacenar en caché respuestas de error incluso si Cloud CDN está inhabilitado.
Limitaciones
Las respuestas de error personalizadas solo son compatibles con el balanceador de cargas de aplicaciones externo global. No se admiten los modos regional ni clásico.
Si no se puede recuperar el objeto de error personalizado del servicio de error (por ejemplo, si la ruta de acceso del contenido está mal configurada), se entrega un objeto de error genérico sin marca.
La política de respuesta de error personalizada no supervisa ni filtra el objeto que muestra el servicio de error en busca de riesgos de seguridad. Por lo tanto, debes ser diligente para eliminar las vulnerabilidades y limitar el impacto de una posible exposición.
Las respuestas de error personalizadas solo son compatibles con los buckets de Cloud Storage que se pueden leer de forma pública.
Para evitar cualquier configuración incorrecta mientras usas un bucket de Cloud Storage, revisa las prácticas recomendadas comunes de Cloud Storage.
Las respuestas de error personalizadas no funcionan si tu balanceador de cargas de aplicaciones externo global solo tiene buckets de backend. Debes tener al menos un servicio de backend conectado al balanceador de cargas, además del bucket de backend.
Los encabezados de respuesta personalizados definidos en función de la fuente de la respuesta de error personalizada no se aplican a las respuestas salientes.
Precios
No se cobra ningún costo adicional por usar respuestas de error personalizadas. Se aplican los precios estándar del balanceo de cargas de Google Cloud. Para obtener más información, consulta Precios.