Resumen

  • HTTP 431 distingue unos campos de solicitud excesivos de un contenido excesivo, pero HTTP no fija el mismo límite para todas las implementaciones ni todos los saltos.
  • El rechazo puede atribuirse al conjunto o a un campo; reducir y reenviar es posible, aunque quitar contexto a ciegas puede alterar autorización, condiciones o destino.

El rechazo llegó antes que el contenido

Una operación pequeña alcanza una pasarela. Su contenido es mínimo o inexistente, pero la solicitud lleva una cookie extensa, credenciales, preferencias, trazas y contexto de reenvío. Cada campo puede parecer normal. Juntos superan el presupuesto que ese receptor eligió.

RFC 6585 dio en 2012 un nombre preciso a la situación: 431 Request Header Fields Too Large. El servidor no quiere procesar la solicitud porque sus campos son demasiado grandes. El cliente puede reducirlos y volver a presentarla.

No es el contenido que RFC 9110 asocia con 413. Los campos son la envoltura de control que explica cómo interpretar, autorizar y encaminar la operación. Por eso la solicitud puede resultar excesiva antes de empezar su cuerpo.

HTTP compartió una respuesta, no un techo

RFC 9110 no establece un máximo predeterminado para una línea, un valor o la sección completa de campos. Aun así, memoria y tiempo de análisis son finitos, de modo que cada implementación decide cuánto acepta.

En una cadena aparecen varios límites. La biblioteca cliente construye el mensaje, un proxy local lo admite, una puerta de borde lo rechaza y otra ruta quizá llegue a un origen con un umbral diferente. Los mismos bytes pueden funcionar en un trayecto y fallar en otro sin contradecir un número universal, porque ese número no existe.

431 da lenguaje común a la decisión privada. Por sí solo no demuestra qué componente impuso el menor presupuesto ni que aumentarlo sea una reparación segura.

Un campo culpable y un total excesivo

RFC 6585 permite usar 431 cuando todo el conjunto es demasiado grande o cuando falla un solo campo. En el segundo caso, la representación debería indicar cuál fue.

Son diagnósticos distintos. Un campo aislado puede acortarse o renovarse si su semántica lo permite. Un exceso agregado puede surgir de muchas adiciones independientes. Eliminar la mayor no garantiza que el total quepa en el siguiente salto. El nombre ayuda a investigar; no certifica compatibilidad de extremo a extremo.

Tampoco identifica necesariamente al responsable. Las cookies acumulan estado de respuestas anteriores, los intermediarios amplían campos de reenvío, la rotación cambia credenciales y los sistemas de trazas añaden contexto fuera de la vista de la aplicación.

Ignorar no conserva el mismo mensaje

RFC 9110 exige un 4xx apropiado cuando los campos superan lo que el servidor quiere procesar. Ignorarlos puede aumentar la exposición a desacuerdos de interpretación y contrabando de solicitudes.

Los campos portan condiciones, credenciales, destino y reglas de interpretación. Si un salto ignora lo que otro utiliza, ambos dejan de actuar sobre la misma solicitud. Truncar puede convertir una escritura condicional en incondicional, borrar autorización o producir dos lecturas de los límites del mensaje.

El servidor también debe recibir toda la sección antes de aplicar el método, porque al final pueden llegar condiciones, credenciales o duplicados engañosos. La salida segura es rechazar de forma explícita y permitir que el dueño de la semántica reconstruya la operación.

Reenviar es una posibilidad, no una promesa

Reducir permite intentar de nuevo, pero no garantiza éxito. Otro intermediario puede tener un límite menor; el campo retirado puede ser obligatorio; la acción puede haber caducado. Con incertidumbre de transporte, tampoco siempre se sabe si un intento previo tuvo efecto.

Un reenvío sólido nace del estado autorizado, conserva condiciones y credenciales necesarias, usa idempotencia cuando la aplicación la ofrece y comprueba que la operación sigue siendo útil. Repetir una solicitud mutilada no restaura su significado.

El caché no hereda el presupuesto

RFC 6585 prohíbe almacenar respuestas 431. El veredicto pertenece a una sección, una ruta y un presupuesto actuales. Reproducirlo después podría negar una solicitud ya reducida o convertir una configuración antigua de un salto en ley para todos.

Un receptor puede crear un 431 nuevo desde su estado. Un caché no puede reutilizar el rechazo como contenido.

Bajo ataque, explicar también cuesta

Los servidores no están obligados a emitir 431. RFC 6585 permite que bajo ataque sea preferible cerrar conexiones o tomar otras medidas. Analizar lo suficiente para construir un diagnóstico consume memoria y CPU; revelar umbrales exactos puede facilitar el sondeo.

Con capacidad disponible, una explicación limitada ayuda al cliente legítimo. Bajo presión, la contención temprana puede tener prioridad. Pero una conexión cerrada no prueba públicamente que el tamaño fuera la causa, así que la evidencia interna debe conservar la diferencia.

La verdad limitada de 431

431 no declara grande el cuerpo, no acredita que se cruzó un máximo de Internet y no prueba malicia. Afirma algo menor: un receptor rechazó una envoltura de control que no estaba dispuesto a procesar.

Esa precisión convirtió un límite oculto en una rama reparable sin estandarizar el presupuesto. La disciplina duradera consiste en mantener el contexto acotado, con dueño y reconstruible, y en no eliminar la autoridad sólo para que el mensaje quepa.

Fuentes