Descripción general de la respuesta de error personalizada

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 tanto el balanceador de cargas como 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.

A continuación, se muestra un ejemplo de una página de error personalizada en la que puedes configurar respuestas de error para tu aplicación orientada al consumidor externo con el desarrollo de la marca y el logotipo de tu empresa, vínculos a páginas relacionadas y mensajes personalizados.

Página de respuesta de error de HTTP personalizada.
Página de respuesta de error de HTTP 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.

Devolver respuestas de error personalizadas te ayuda a mejorar la experiencia de tus usuarios, ya que ofrece los siguientes beneficios:

  • Proporciona una experiencia de marca coherente
  • Proporciona información contextual y pertinente 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 publicará un objeto de error genérico sin marca, como se muestra en la figura 2.

Página de respuesta de error de HTTP genérica.
Página de respuesta de error de HTTP genérica

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 información y la marca de la empresa cuando tus servidores de backend no estén en buen estado o estén 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 el 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 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 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 en función de los encabezados y parámetros de 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 del 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 del dominio de la URL. La política se aplica al tráfico dirigido a un nombre de dominio o un nombre de host específicos, 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 aplicada a nivel del balanceador de cargas, del dominio de la URL y de la ruta de URL del mapa de URL.

Nivel de la política Campo de API
Balanceador de cargas urlMaps.defaultCustomErrorResponsePolicy
Dominio de URL pathMatchers[].defaultCustomErrorResponsePolicy
Ruta de URL

pathMatchers[].pathRules[].customErrorResponsePolicy

pathMatchers[].routeRules[].customErrorResponsePolicy

Si configuras una política de respuesta de error personalizada en varios niveles del recurso del mapa de URL, se devolverá 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 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. Para obtener más información sobre esta configuración, consulta Cómo configurar 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 tendrán prioridad.

Por ejemplo, supón 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 devuelve un código de error 401, se aplica la regla que coincide con el error 401. Sin embargo, si el servicio de backend devuelve 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 devuelve 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, incluidos 200 (OK), las series 4xx o 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 del 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 devuelve 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

Se puede almacenar en caché una respuesta de error personalizada si se especifica 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é 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 devuelve un código que no es de error (HTTP 200) como código de respuesta de anulación, no se aplica una política de almacenamiento en caché negativo.

Si no transcurrió el tiempo de actividad (TTL) de la respuesta de error, el balanceador de cargas sigue 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.

  1. 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, la devuelve. Esta respuesta almacenada en caché puede ser el contenido solicitado por el usuario o un objeto de error personalizado.

  2. Si no hay error de caché, el balanceador de cargas procesa la solicitud y la envía al backend.

  3. Si el backend entrega una respuesta sin errores, esta se devuelve al usuario final. Sin embargo, si una solicitud del cliente encuentra un error (un código de respuesta HTTP 4xx o 5xx), el balanceador de cargas intenta obtener el objeto de error personalizado del servicio de error que especificaste de la siguiente manera:

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

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

    3. 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 regionales ni clásicos.

  • Si no se puede recuperar el objeto de error personalizado del servicio de errores (por ejemplo, si la ruta de acceso al 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 devuelve 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 se admiten en los buckets de Cloud Storage que se pueden leer de forma pública.

    Para evitar errores de configuración cuando uses un bucket de Cloud Storage, revisa las prácticas recomendadas para 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 que se definan en función de la fuente de la respuesta de error personalizada no se aplicarán a las respuestas salientes.

  • La política de respuesta de error personalizada solo se aplica a las respuestas HTTP que provienen de los backends. Si la respuesta proviene del servidor de Google Front End (GFE), es posible que veas otros códigos de respuesta HTTP inesperados.

  • Las respuestas de error personalizadas no son compatibles con los siguientes tipos de solicitudes:

    • Son solicitudes con cuerpos que activan una política de inserción de fallas.
    • Solicitudes grandes en las que el servicio de backend envía una respuesta antes de leer el cuerpo por completo.
    • Solicitudes que incluyen un encabezado Authorization Si una solicitud incluye un encabezado Authorization, Cloud Storage devuelve una respuesta Authentication Required.

Precios

No se aplican costos adicionales 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.

¿Qué sigue?