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 externa de consumidor con la marca y el logotipo de tu empresa, vínculos a páginas relacionadas y mensajería personalizada.
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.
Mostrar respuestas de error personalizadas te ayuda a mejorar la experiencia de los usuarios, ya que ofrece los siguientes beneficios:
- Brinda una experiencia coherente de desarrollo de la marca.
- 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 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 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 según códigos de error específicos. Por ejemplo, puedes configurar una página de error con un mensaje de “Acceder o registrar” 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 a fin de 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 solicitud HTTP, por ejemplo, el encabezado Content-Type. Cuando se enruta la solicitud original al servicio de error, el enrutamiento puede tener en cuenta que el encabezado Content-Type entrega una página web (para solicitudes de navegadores) o JSON (para solicitudes de un 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 de dominio de URL y el nivel de 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 que se dirige a un nombre de dominio específico o a un nombre de host, por ejemplo,
www.example.com.Nivel de la 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 solicitudes HTTP, por ejemplo,Content-Type:application/json.
En la siguiente tabla, se muestra una política de respuesta de error personalizada aplicada a nivel del balanceador de cargas, de dominio de URL y de la ruta de URL del mapa de URL.
| Nivel de 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 de 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 de dominio de la 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: la ruta de URL. A fin de 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 dentro 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 y 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 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. Si deseas obtener más información sobre cómo anular el código de respuesta, consulta Configura 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 nuevo campo overrideResponseCodeServed en los registros de balanceo de cargas. Este campo solo se propaga para las 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 una política de respuesta de error personalizada modifica el código de respuesta.
Almacena en caché las respuestas de error personalizadas
Una respuesta de error personalizada se puede almacenar en caché si especificas una política de almacenamiento en caché negativo 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é negativo 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 sin error (HTTP 200) como un código de respuesta de anulación, no se aplica una política de almacenamiento en caché negativo.
Si no ha transcurrido el tiempo de actividad (TTL) para la respuesta de falla, el balanceador de cargas continúa entregando contenido almacenado en caché sin enrutar la solicitud a un servicio de backend o a 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 esa respuesta al usuario. Esta respuesta almacenada en caché puede ser el contenido que solicitó el usuario o un objeto de error personalizado.
Si hay un error de 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 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 de error personalizado.
El balanceador de cargas muestra 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 regionales ni clásicos.
Si el objeto de error personalizado no se puede recuperar del servicio de errores, por ejemplo, si la ruta de 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 para detectar riesgos de seguridad. Por lo tanto, debes ser cuidadoso con la eliminación de vulnerabilidades y la limitación del 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.
Si deseas evitar una configuración incorrecta mientras usas un bucket de Cloud Storage, consulta las prácticas recomendadas comunes para Cloud Storage.
Precios
No se aplican costos adicionales por usar respuestas de error personalizadas. Se aplica el precio estándar para el balanceo de cargas de Google Cloud. Para obtener más información, consulta Precios.