Summary

  • RFC 6265 explica el trayecto de Set-Cookie a Cookie: el servidor entrega pares de nombre y valor; el navegador devuelve los que corresponden a la siguiente petición. El texto pide a los servidores que sean parcos con ese estado.
  • RFC 6585 introdujo en abril de 2012 el 431 para cabeceras excesivas en conjunto o para un campo demasiado grande. Una petición reducida puede repetirse; la respuesta 431 no debe guardarse en caché.
  • HTTP/2 y HTTP/3 conservan la facultad del servidor de rechazar un bloque o una sección de cabeceras que exceda lo que está dispuesto a procesar.

El equipaje lo preparó la tienda

Una persona vuelve a una tienda en línea. El navegador solicita la portada y añade Cookie con la sesión, una preferencia y varios valores que el propio sitio le había pedido conservar. La puerta de entrada tiene una cota para las cabeceras. El conjunto la rebasa. La petición recibe 431 y la tienda no deja pasar al cliente que regresa con el equipaje que ella misma preparó.

El circuito figura en la norma RFC 6265, de abril de 2011. Una respuesta Set-Cookie deposita un par nombre-valor en el agente de usuario. En posteriores visitas, el navegador decide si el dominio, la ruta y otras condiciones hacen aplicable ese par y lo inserta en Cookie. Los atributos que delimitan el alcance y la caducidad no se devuelven como pares; sí vuelven el nombre y el valor. Lo que empezó como una decisión del servidor reaparece en cada petición que encaja en ese alcance.

La propia RFC muestra la tensión en sus cifras. Pide a los navegadores de uso general capacidad para al menos 4096 bytes por cookie y para al menos 50 cookies por dominio. En el mismo apartado pide a los servidores pocas cookies y pequeñas, porque la cabecera Cookie viaja en cada solicitud. Los 4096 bytes miden un mínimo de almacenamiento del navegador. Cada servidor y cada intermediario establecen por separado cuánto están dispuestos a leer en las cabeceras de una petición. La memoria de un extremo puede superar la ventanilla del otro.

El 431 identifica el atasco

En abril de 2012, RFC 6585 incorporó cuatro códigos de estado. El 431, Request Header Fields Too Large, sirve cuando la suma de los campos es excesiva o cuando lo es uno solo. En el segundo caso, la representación de la respuesta debería señalar el campo culpable. Se permite volver a enviar la petición después de reducir las cabeceras. La respuesta 431 no puede almacenarse en una caché: una negativa ligada a esta petición no debe reciclarse para otra que llegue con otros campos.

La norma hizo visible una causa, pero no fijó un límite único en bytes. Tampoco instruyó al navegador sobre qué cookie borrar ni ordenó al operador retirar el valor que la produjo. Y un 431 ni siquiera está garantizado: en situación de ataque, el servidor puede cortar la conexión en vez de contestar. Para el visitante, un fallo sin explicación puede parecer una caída general. Para el equipo técnico, es decisivo saber si se detuvo en una pasarela, en un proxy o en el origen.

El remedio de borrar todas las cookies resulta tentador porque aligera la petición. También puede cerrar la sesión y perder preferencias. Si el mismo sitio vuelve a emitir valores grandes, el visitante habrá repetido el trabajo sin alterar la causa. Una ruta de recuperación capaz de admitir una petición pequeña ofrece una salida más útil que una página de ayuda situada detrás del mismo límite.

Comprimir el viaje no ensancha la puerta

Los protocolos posteriores conservaron el problema. RFC 9113, publicada en 2022 para HTTP/2, permite al servidor responder 431 si recibe un bloque de campos mayor de lo que acepta. RFC 9114 dice lo mismo para una sección de cabeceras HTTP/3. La compresión puede abaratar los bytes transmitidos. Al destino le queda la colección de campos que debe interpretar y para la que fijó un presupuesto.

En una investigación, dos gráficos pueden contar historias distintas: pocos bytes comprimidos en la red y demasiadas cabeceras tras la decodificación. También hay que separar una cookie enorme de la suma de muchas pequeñas. El 431 cubre ambas formas de exceso, y Cookie comparte el presupuesto con autorizaciones y otros campos. Las RFC no ofrecen una cifra de incidentes reales causados por cookies. El hecho que decide un caso concreto es una captura de la petición en el primer componente que la rechazó.

El valor histórico de 431 está en el reparto de responsabilidades. El navegador transporta el estado. Una pasarela decide si cabe. La aplicación quizá no recibe nunca la petición. El emisor conoce qué valores creó, cuánto duran y a qué rutas se envían. Por eso puede reducir el equipaje antes de que se convierta en un problema para la persona que vuelve. El número del error da una pista. La política de estado del sitio decide si la puerta vuelve a abrirse.