Entrevista general: ¿Cómo diagnosticas HTTP 431 Request Header Fields Too Large?

1. Pregunta y contexto

Después de iniciar sesión, una página accede a una API a través de una CDN, un balanceador de carga y una malla de servicios. Algunos usuarios reciben 431 Request Header Fields Too Large; una ventana de incógnito y curl funcionan. Explica la semántica del estado, el diagnóstico salto a salto, la remediación y la validación del lanzamiento. Asume que se puede usar HTTP/1.1 o HTTP/2 y que los registros no pueden contener cookies completas ni valores de autorización.

2. Qué evalúa el entrevistador

• Distinguir un bloque de encabezados agregado sobredimensionado de un solo campo sobredimensionado y saber que 431 es una respuesta de error del cliente antes del procesamiento de la solicitud.
• Medir a través de la CDN, el gateway, el proxy y la aplicación en lugar de cambiar solo el servidor de aplicaciones.
• Reconocer el crecimiento de cookies, valores duplicados de Set-Cookie, tokens largos y encabezados de reenvío como causas probables.
• Reducir el estado del cliente, rotar credenciales y agregar observabilidad de tamaño sin debilitar la seguridad.

3. Preguntas para aclarar primero

1. ¿Qué salto generó el 431 y pueden los encabezados de respuesta, la identidad del servidor o los registros del edge identificarlo?
2. ¿Cuáles son los bytes totales de encabezados de la solicitud fallida, el campo más grande y el protocolo?
3. ¿El navegador envía cookies antiguas, cookies entre subdominios o datos de sesión en crecimiento?
4. ¿Limita cada capa los encabezados agregados, un campo, la línea de solicitud o los búferes, y existen límites de decodificación de HTTP/2?

4. Una respuesta de 30 segundos

431 significa que el servidor rechazó la solicitud porque los encabezados agregados de la solicitud o un campo excedieron un límite permitido; el RFC 6585 no define un límite de bytes universal único. Mide totales redactados y los campos más grandes desde el cliente a través del edge, gateway, proxy y aplicación, luego encuentra el primer salto que devuelve 431. Cuando solo fallan los navegadores, inspecciona cookies, Set-Cookie duplicados y la autorización antes de aumentar los límites. Elimina el estado del cliente, acorta o reemplaza tokens con referencias de sesión del lado del servidor, expira cookies antiguas y alinea presupuestos a través de los saltos. Aumenta un límite solo después de un análisis de capacidad y de denegación de servicio.

5. Respuesta paso a paso

Paso 1: Confirmar el estado y el salto emisor

Registra los nodos atravesados, el protocolo, los encabezados de respuesta y el ID de correlación. Reproduce una solicitud mínima directamente al origen, evitando la CDN, a través del gateway y con encabezados de navegador redactados; compara dónde aparece por primera vez el 431. Algunos proxies usan 400 o un código de proveedor como 494 para un límite similar, por lo que debes combinar el estado con los registros y la configuración del nodo.

Paso 2: Medir los encabezados en bytes

Calcula la longitud en bytes codificados para cada campo y registra el total de encabezados de solicitud, la línea de solicitud, el campo más grande y la cantidad de campos. El recuento de caracteres no es el recuento de bytes, y un bloque de encabezados HTTP/2 comprimido no es el total de campos decodificados. Mantén solo nombres de campo, longitudes, prefijos hash e IDs de solicitud en los registros; nunca registres valores de cookies, tokens de portador ni un Referer completo.

Paso 3: Encontrar fuentes exclusivas del navegador

Las cookies son el principal sospechoso: cookies con el mismo nombre en varias rutas o subdominios, datos de usuario almacenados en cookies y un nuevo valor adjuntado en cada respuesta hacen que las solicitudes posteriores crezcan. Inspecciona el Domain, Path, la expiración y el comportamiento de eliminación de Set-Cookie; verifica que el nombre antiguo realmente expire en lugar de sobrescribirse solo en una ruta. Mantén los tokens de autorización cortos y coloca los datos mutables en una sesión controlada del lado del servidor o en un almacén seguro.

Paso 4: Considerar los saltos de proxy y HTTP/2

Cada salto puede tener diferentes límites agregados, por campo y de búfer, mientras que el reenvío agrega X-Forwarded-*, rastreo y campos de autenticación. Publica el presupuesto como un contrato de configuración y usa el límite más pequeño como el tope de diseño del cliente. HTTP/2 usa HPACK para la compresión de transporte, pero los endpoints aún decodifican campos y aplican límites; la tasa de compresión no demuestra que los encabezados de negocio sean seguros. Alerta sobre los rechazos del gateway cuando la aplicación no recibe nada.

Paso 5: Elegir remediación y defensas

Elimina cookies duplicadas, reduce el contenido de la sesión, traslada el estado al lado del servidor y envía solo una referencia corta e impredecible. Establece políticas de longitud, rotación y revocación de tokens; rechaza campos personalizados desconocidos o inusualmente grandes. Aumenta los límites solo después de verificar la memoria de análisis sintáctico, la concurrencia y el costo de denegación de servicio, con presupuestos sensatos por inquilino o por ruta.

6. Respuesta modelo

Identificaría el primer salto que devuelve 431 y mediría la solicitud fallida después de la redacción: bytes totales de encabezados, campo más grande, línea de solicitud, cantidad de campos y versión de HTTP. Un fallo exclusivo en el navegador apunta primero a cookies duplicadas o entre subdominios, datos de sesión en crecimiento o longitud de autorización; cambiar solo el límite del origen es inseguro porque una CDN, un balanceador de carga o una malla pueden rechazar antes. Expiraría cookies antiguas, minimizaría el estado del cliente, usaría una referencia de sesión del lado del servidor y alinearía los presupuestos de los saltos. La compresión de transporte de HTTP/2 no elimina los límites decodificados. La telemetría de producción agregaría percentiles de tamaño por salto y nombre de campo mientras almacena longitudes y prefijos hash, nunca credenciales.

7. Errores comunes

• Solo borrar las cookies del navegador: Puede ser temporal; rastrea el configurador, el Domain, el Path y la lógica de expiración para eliminar la causa raíz del Set-Cookie duplicado.
• Asumir que 431 siempre significa 8 KB: El RFC 6585 no establece un límite universal; inspecciona cada capa y mide los bytes.
• Aumentar solo el límite del origen: Un edge o gateway aún puede rechazar primero, y el costo de análisis sintáctico crece; alinea presupuestos y evalúa la capacidad.
• Registrar encabezados de solicitud completos: Esto expone cookies y tokens; conserva nombres, longitudes, prefijos hash e IDs de correlación.
• Asumir que la compresión HTTP/2 elimina los límites: Los endpoints decodifican campos y aplican límites; prueba la compresión de transporte por separado del tamaño decodificado.

8. Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué funciona curl mientras que el navegador falla?

Los navegadores envían automáticamente todas las cookies, encabezados de autenticación y seguimiento que coinciden con el dominio; curl suele ser más pequeño. Exporta una solicitud del navegador, elimina campos mediante búsqueda binaria y mide cada salto para separar el contenido del cliente de los límites del proxy.

Pregunta de seguimiento 2: ¿Se puede almacenar un JWT en una cookie?

Se puede, pero cada solicitud paga el costo en bytes del token y varias cookies pueden exceder un límite. Mantén una referencia corta o claims mínimos en el lado del cliente, almacena datos mutables y revocación en el lado del servidor, y aplica presupuestos de longitud y rotación.

Pregunta de seguimiento 3: ¿Cuándo es aceptable aumentar el límite?

Solo cuando el requisito es real, cada salto puede absorber la memoria de análisis sintáctico y la concurrencia, y las pruebas de capacidad, tiempo de espera y denegación de servicio se aprueban. Mantén telemetría de tamaño, límites de tasa y una configuración de reversión; un tope más alto no es la única solución.