Las cabeceras reenviadas y relacionadas con el host enviadas a backends HTTP no coinciden con las expectativas del backend

Emitir síntomas

Es posible que vea uno o más de los siguientes síntomas:

• El servicio de backend espera Forwarded: host=<client-hostname>, pero falta el valor.

• El servicio de backend solo recibe entradas Forwarded: for=....

• El servicio de backend recibe el nombre de host de destino de backend en la cabecera Host en lugar del nombre de host orientado al cliente.

• Las redirecciones, las URL generadas o la lógica de control de acceso basada en host funcionan de manera diferente después de que la API se coloca detrás de API Gateway.

• El servicio backend recibe varios valores Forwarded o X-Forwarded-For y la aplicación solo maneja un valor.

Causas posibles

Las discrepancias de encabezados de host y reenviados pueden producirse por los siguientes motivos:

• La aplicación espera Forwarded: host=... o Forwarded: proto=..., pero API Gateway solo agrega una entrada for=... por defecto.

• La aplicación lee la cabecera Host, pero API Gateway reescribe esa cabecera para el destino backend.

• La aplicación espera un único valor de reenvío, pero la solicitud contiene una cadena de reenvío.

• El despliegue no incluye una transformación de cabecera de solicitud que transfiera el host orientado al cliente al backend.

Descripción del comportamiento de cabecera reenviada

Para backends HTTP, API Gateway agrega cabeceras de solicitud que contienen información de IP de cliente.

La solicitud al backend puede incluir las siguientes cabeceras:

• X-Real-IP

• Forwarded

• X-Forwarded-For

• User-Agent: Oracle API Gateway

El valor Forwarded por defecto es una entrada for=.... API Gateway no agrega automáticamente los valores host=... o proto=... a la cabecera Forwarded.

Si el cliente envía cabeceras de reenvío existentes, API Gateway conserva esos valores y agrega su propia información de IP de cliente. Por lo tanto, el backend puede recibir una cadena de valores Forwarded o X-Forwarded-For.

Descripción del comportamiento de la cabecera del host

Para backends HTTP, la cabecera Host de la solicitud al backend no es el host original orientado al cliente por defecto. El gateway de API reescribe la cabecera Host para el destino backend.

Si la aplicación necesita el host orientado al cliente, configure una transformación de cabecera de solicitud que copie el valor Host entrante en una cabecera que lea la aplicación. Por ejemplo, utilice la variable de contexto request.host para copiar el host entrante en X-Forwarded-Host o en una cabecera específica de la aplicación.

No confíe en la cabecera Host de la solicitud backend para conservar el nombre de host externo.

Revisar cabeceras recibidas

Repita la solicitud a través de API Gateway e inspeccione las cabeceras que recibe el backend.

Revise los siguientes valores de cabecera:

• Cabecera Forwarded visible de backend.

• Cabecera X-Forwarded-For visible de backend.

• Cabecera Host visible de backend.

• Cabecera X-Forwarded-Host visible de backend, si la ruta utiliza esa cabecera.

• Cualquier cabecera personalizada que cree el despliegue a partir del valor Host entrante.

Si es posible, utilice un punto final temporal que se haga eco de las cabeceras de solicitud. La respuesta repetida muestra los valores de cabecera que llegaron al backend.

Revisión de la configuración de despliegue

Revise la configuración de despliegue de API en API Gateway para identificar la ruta coincidente y cualquier transformación de cabecera de solicitud en esa ruta.

Confirme los siguientes valores de configuración:

• Valor backend.url para la ruta.

• El valor routes.path que coincide con la solicitud.

• Las transformaciones de cabecera de solicitud en la ruta coincidente.

Si el backend depende del nombre de host orientado al cliente, confirme que la ruta copia el valor Host entrante en una cabecera que el backend pueda leer.

Si el backend depende de Forwarded: host=..., confirme que su propia estrategia de cabecera define ese valor. No suponga que API Gateway crea el valor automáticamente.

Corrección de problemas de cabecera de host y reenvío

Aplique la corrección que coincida con el valor de cabecera que necesita el backend:

• Si el backend puede utilizar X-Forwarded-Host, configure la ruta para enviar esa cabecera y actualice la aplicación para leerla.

• Si el backend necesita el host orientado al cliente en una cabecera personalizada, cree una transformación de cabecera de solicitud a partir del valor Host entrante.

• Si el backend espera Forwarded: host=..., actualice la aplicación para que utilice las cabeceras que proporciona API Gateway o agregue una estrategia de cabecera explícita que la aplicación pueda consumir.

• Si el backend analiza solo un valor Forwarded o X-Forwarded-For, actualice la aplicación para manejar una cadena de reenvío.

Verificación de encabezados de host y reenvío

Después de actualizar la lógica de despliegue o de aplicación, repita la solicitud y verifique el resultado.

Confirme los siguientes resultados:

• El backend recibe el valor de host esperado orientado al cliente en la cabecera configurada.

• El backend maneja varios valores Forwarded o X-Forwarded-For correctamente.

• Los redireccionamientos, las URL generadas y la lógica basada en host utilizan el esquema y el nombre de host esperados.

• La lógica de control de acceso basada en host devuelve la respuesta esperada.

Para obtener más información

Para obtener más información, consulte:

• Agregación de una URL de HTTP o HTTPS como backend de gateway de API

• Transformación de solicitudes entrantes y respuestas salientes

• Agregación de variables de contexto a políticas y definiciones de backend HTTP

• Errores varios al llamar a las API