¿Los límites de tamaño descodificado protegen a un agente de las API comprimidas?

Una respuesta comprimida no es pequeña porque haya llegado pequeña. Solo lo es hasta que el cliente la descodifica, analiza, almacena, registra y quizá se la entrega a un agente que la trata como evidencia. Si impones un límite solo a los bytes recibidos de la red, has medido la parte menos interesante de la transacción.

He visto equipos añadir un límite HTTP de 5 MB que parecía razonable, celebrar que la prueba saliera bien y descubrir después que unos pocos kilobytes de datos repetidos comprimidos podían producir una respuesta lo bastante grande como para bloquear un proceso o contaminar la ejecución de un agente. No hizo falta ningún ataque exótico. Un endpoint devolvió un informe con un campo repetido muchas más veces de lo esperado, la compresión hizo muy bien su trabajo y el cliente cometió la acción peligrosa: recopiló el cuerpo descodificado antes de decidir si lo quería.

Los límites de tamaño descodificado deben aplicarse al flujo descodificado, antes de que un analizador, un registrador, una caché o el contexto de un agente consuma el cuerpo. Mantén otro límite para los bytes de red, porque así detienes transferencias lentas o inesperadamente grandes. Ambos límites cubren fallos distintos. Confundirlos convierte una comprobación defensiva en una falsa sensación de seguridad.

El tamaño en la red solo cuenta una parte de la historia

Content-Length normalmente describe el cuerpo del mensaje HTTP tal como se transfiere. Cuando la respuesta tiene Content-Encoding: gzip o Content-Encoding: br, ese recuento describe bytes comprimidos. Un cuerpo de 40 KB puede expandirse a decenas o cientos de megabytes tras descodificarlo si contiene suficientes repeticiones. La proporción exacta no es lo importante. Basta cualquier proporción que supere tu presupuesto de asignación o de contexto para causar problemas.

RFC 9110 trata la codificación de contenido como una transformación aplicada a una representación. Esa redacción importa. La representación que usa tu aplicación es la forma descodificada, mientras que el transporte lleva una forma codificada. Un cliente que basa el límite de su aplicación en la forma de transporte ha puesto la protección al lado equivocado de la transformación.

Transfer-Encoding complica aún más el panorama. La transferencia fragmentada no ofrece un Content-Length final útil en el que un cliente pueda confiar, y una respuesta HTTP/2 o HTTP/3 no usa la transferencia fragmentada de la misma forma. Incluso cuando hay una cabecera, un servidor puede enviar un valor incorrecto. Usa la cabecera como una pista para rechazar antes, nunca como prueba de que el cuerpo es seguro.

Hay tres cantidades que conviene registrar para una respuesta: bytes de red leídos, bytes descodificados producidos y bytes retenidos para quien llama. A veces serán iguales. A menudo no lo serán. Una respuesta JSON puede descodificarse a 12 MB, ocupar mucha más memoria que esos 12 MB al analizarse y luego requerir un recorte a 64 KB antes de que un agente pueda usarla con seguridad.

Esta distinción también evita una discusión frecuente sobre un único ajuste de «tamaño máximo de respuesta». Una persona se refiere a los bytes del socket. Otra, a los bytes descodificados. Una tercera, al texto insertado en el resultado de una herramienta. Da a cada límite su propio nombre y aplícalo en el límite que describe.

Descodifica antes de acumular datos sin límite

El orden seguro es sencillo: limita el flujo de respuesta sin procesar, selecciona e inicializa el descodificador, limita el flujo descodificado y después analiza o retén solo lo que necesite quien llama. No uses un método práctico que lea toda la respuesta descodificada en un segmento de bytes y compruebe su longitud después. Para entonces, el descodificador ya habrá gastado la memoria que intentabas conservar.

Para una respuesta gzip en Go, el limitador descodificado debe rodear al lector gzip. Este ayudante lee deliberadamente un byte más de lo permitido. Sin ese byte adicional, una respuesta cuyo tamaño real coincide exactamente con el límite no se puede distinguir de una respuesta mayor cortada en el límite.

var ErrDecodedBodyTooLarge = errors.New("decoded response exceeds limit")

func readGzipBody(r io.Reader, limit int64) ([]byte, error) {
    zr, err := gzip.NewReader(r)
    if err != nil {
        return nil, err
    }
    defer zr.Close()

    bounded := &io.LimitedReader{R: zr, N: limit + 1}
    body, err := io.ReadAll(bounded)
    if err != nil {
        return nil, err
    }
    if int64(len(body)) > limit {
        return nil, ErrDecodedBodyTooLarge
    }
    return body, nil
}

Aplica también un límite sin procesar antes de gzip.NewReader. Ese límite no sustituye al límite descodificado. Evita que un par envíe un flujo comprimido enorme y limita cuánto trabajo acepta el cliente antes de que el descodificador tenga suficiente entrada para avanzar.

No trunques en silencio y sigas adelante. Un documento JSON truncado suele fallar al analizarse, pero un protocolo de texto o de líneas truncado puede parecer verosímil. Si conservas una vista previa para diagnóstico, márcala como vista previa en un campo que no pueda confundirse con el cuerpo completo. La acción debe fallar porque el cliente no obtuvo una respuesta completa y permitida.

Un descodificador puede detectar una suma de comprobación corrupta solo cuando llega al final del flujo. Cuando se activa el límite descodificado, deja de leer y rechaza la respuesta. No necesitas terminar de verificar un cuerpo demasiado grande que ya has decidido descartar. Si la respuesta permanece por debajo del límite, lee hasta EOF y deja que el descodificador informe normalmente de un truncamiento o una corrupción.

Una respuesta puede agotar el contexto antes que la memoria

Proteger la memoria es necesario, pero las herramientas de agentes tienen otro presupuesto: la cantidad de texto de resultado que puede entrar con seguridad en la conversación del agente. Una respuesta JSON de 2 MB puede ser inofensiva para un proceso de escritorio y seguir siendo un resultado terrible para una herramienta. Puede desplazar la tarea, llevar al agente a perseguir registros irrelevantes u obligar al modelo a razonar sobre una representación parcial que parece completa.

No uses el presupuesto de contexto como motivo para elevar el límite del cuerpo descodificado. Protegen operaciones distintas. El límite descodificado permite que el transporte y el analizador terminen con seguridad. El límite de presentación controla lo que recibe el agente después de una descodificación correcta y, cuando corresponde, de un análisis estructurado.

Para datos estructurados, elige una proyección en lugar de cortar bytes arbitrarios. Si un endpoint devuelve una lista de registros, conserva un número limitado de registros y una cantidad limitada de texto por campo. Incluye el número total de registros solo si el analizador lo obtuvo sin retener la lista completa. Indica que el resultado se redujo y explica la regla de selección, por ejemplo: «los primeros 50 registros ordenados por marca de tiempo». Eso hace que el resultado se pueda auditar y evita que un agente trate un fragmento como una búsqueda exhaustiva.

Para texto sin formato, conserva líneas completas cuando sea posible. Una vista previa de registro que termina a mitad de línea es menos útil y puede ocultar el campo que la explica. Define un presupuesto de bytes, lee línea por línea con un límite de longitud de línea e informa tanto del recuento retenido como de la razón por la que se omitió contenido adicional. Un lector de líneas sin su propio límite de tamaño de token solo traslada el problema de asignación a otro ayudante.

Aquí es donde se derrumba gran parte del razonamiento de «el modelo puede resumirlo». El modelo puede resumir datos que seleccionaste deliberadamente. No puede hacer seguro un transporte sin límite, y no debería decidir cuánta salida remota sin procesar asigna tu proceso antes de que la hayas comprobado.

La codificación de contenido debe ser explícita en el contrato del cliente

Trata Content-Encoding como una entrada que selecciona un descodificador, no como un adorno alrededor de un flujo de bytes idéntico. Acepta solo las codificaciones que implemente tu cliente y rechaza claramente los valores desconocidos. Si un servicio devuelve gzip, usa la ruta gzip. Si devuelve br, usa un descodificador Brotli envuelto en el mismo limitador de bytes descodificados. Si no devuelve codificación de contenido, envuelve el cuerpo sin procesar en ese limitador descodificado porque, en ese caso, los bytes sin procesar también son bytes descodificados.

No aceptes varias codificaciones de contenido a la ligera. HTTP permite una lista de codificaciones y las transformaciones indicadas tienen un orden. Admitir gzip, br significa que debes descodificar en orden inverso y aplicar una protección de tamaño después de cada etapa de expansión. Un único límite final es más débil de lo que parece porque una etapa intermedia puede crecer mucho antes de que la etapa final la reduzca. Si tus integraciones no requieren codificaciones apiladas, recházalas hasta que cuentes con pruebas y una implementación deliberada.

La descompresión automática merece una revisión. Muchas bibliotecas HTTP añaden Accept-Encoding, descodifican gzip y ocultan el cambio al código de aplicación. Eso resulta práctico para solicitudes normales, pero puede hacer que el código cuente los bytes en la capa equivocada. Averigua si el cuerpo de respuesta devuelve bytes de red o bytes descodificados, si la biblioteca elimina Content-Encoding y si expone recuentos de bytes comprimidos. Escribe una prueba que demuestre el comportamiento con la configuración exacta de tu cliente.

Brotli merece el mismo tratamiento que gzip. Es tentador escribir una prueba gzip porque todos los entornos tienen un comando gzip y dar el trabajo por terminado. Un descodificador distinto implica otro manejo de errores, otro comportamiento de almacenamiento en búfer y otro soporte según las versiones de dependencias. El límite debe rodear el lector devuelto por cada descodificador, no estar en un ayudante al que solo llama la ruta gzip.

Un servidor también puede enviar una codificación declarada con un cuerpo inválido. Conserva eso como error de descodificación, distinto de una respuesta descodificada demasiado grande. Quienes operan el sistema necesitan saber si el lado remoto envió datos incorrectos, el presupuesto configurado era demasiado bajo o el cliente no tiene descodificador para una codificación declarada.

Prueba la expansión con archivos que puedas inspeccionar

Un archivo de prueba útil parte de contenido descodificado que puedes reconocer y medir. Los bytes repetidos ofrecen un caso de expansión evidente. Los siguientes comandos crean un cuerpo de texto de 32 MiB y luego versiones gzip y Brotli cuando está instalado el comando Brotli.

python3 -c 'open("repeat.txt", "wb").write(b"A" * (32 * 1024 * 1024))'
wc -c repeat.txt
gzip -9 -c repeat.txt > repeat.txt.gz
brotli -f repeat.txt -o repeat.txt.br
wc -c repeat.txt.gz repeat.txt.br

La primera salida de wc debe tener la forma 33554432 repeat.txt. Los archivos comprimidos deberían ser mucho más pequeños que el original porque la entrada repite un byte. No hagas que una prueba exija un tamaño comprimido concreto. Las versiones y los ajustes de compresión pueden cambiarlo. Comprueba la longitud descodificada, el resultado del cliente y que el cliente no retuvo ningún cuerpo completo tras rechazarlo.

Construye casos límite a partir de la misma fuente: un cuerpo descodificado un byte por debajo del límite configurado, otro exactamente en el límite y otro un byte por encima. Prueba cada caso mediante un controlador HTTP local que configure correctamente Content-Encoding. Una prueba de descodificador de archivos es útil, pero no puede detectar una biblioteca cliente que realiza descompresión automática antes de que se ejecute tu código de límite.

Usa una segunda familia de archivos de prueba con una estructura realista. Genera JSON delimitado por saltos de línea donde cada registro tenga un campo de carga repetido y sírvelo con gzip y Brotli. Esto detecta código que maneja correctamente un segmento de bytes pero deja que un analizador JSON o un escáner de líneas construya una matriz sin límite después de descodificar. Incluye un registro más largo que tu límite de campo o línea, porque un atacante no necesita repetir líneas cortas para forzar una asignación del analizador.

Conserva los archivos de prueba en el repositorio solo si sus formas comprimidas son pequeñas y su fuente puede generarse durante las pruebas. Un script generador que produce una longitud descodificada conocida es más fácil de revisar que un blob binario misterioso. Registra el tamaño descodificado previsto en el nombre de la prueba, no solo en un comentario que nadie ve cuando falla un caso límite.

El fallo suele empezar con un método práctico y aparentemente útil

Considera un agente que llama a una API para obtener datos de incidencias. El endpoint suele devolver una página JSON pequeña. El cliente envía Accept-Encoding: gzip, recibe una respuesta cuyo Content-Length es 18 KB y registra la cabecera como prueba de que el resultado es modesto. Después, su ayudante HTTP descomprime el cuerpo de forma transparente y llama a ReadAll antes de analizar JSON.

Una respuesta defectuosa del proveedor contiene un gran campo de descripción repetido en cada registro. La transferencia de 18 KB se expande a muchos más datos de los que normalmente tendría la página. El proceso asigna el segmento de bytes, crea después cadenas y mapas durante el análisis y serializa registros seleccionados para el agente. Cada etapa conserva una copia distinta durante al menos parte de la solicitud. Un límite colocado después del análisis detecta el problema solo después de que ya haya ocurrido el trabajo costoso.

La primera reparación suele añadir if len(body) > limit después de ReadAll. Esa prueba hace que la prueba unitaria parezca correcta mientras mantiene el pico de asignación. La segunda reparación envuelve el lector descodificado, que va en la dirección correcta, pero sigue enviando al agente los primeros limit bytes como alternativa. Ahora el agente puede actuar basándose en media respuesta, y el registro de auditoría no muestra un fallo limpio.

La reparación completa rechaza pronto en el lector descodificado, descarta el contenido parcial, registra la codificación y el presupuesto de bytes y proporciona a quien llama un error que pueda clasificar. Si el endpoint realmente necesita exportaciones grandes, lleva ese caso de uso a una ruta de descarga explícita con un límite aprobado más alto, un destino elegido por el usuario y sin insertar automáticamente el archivo en el contexto del agente.

Esta separación importa porque descargar un informe y consultar una herramienta de agente son operaciones distintas. Que ambas hagan una solicitud HTTP no hace que tengan el mismo riesgo ni el mismo presupuesto.

Los límites necesitan una persona responsable del endpoint y una razón

Un valor predeterminado global es un punto de partida, no una política que sirva para cada acción HTTP. Asigna un límite de respuesta descodificada según el resultado previsto del endpoint. Una comprobación de estado puede necesitar solo unos pocos kilobytes. Una búsqueda paginada puede devolver una respuesta estructurada moderada. Una exportación binaria puede requerir un límite mayor, pero debería ir a una ruta de archivo en vez de a un resultado conversacional.

Escribe el límite junto a la definición de la acción y explica el motivo. «La documentación de la API dice que el tamaño de página es 100» no basta porque un registro puede seguir siendo enorme. Un motivo útil nombra la representación esperada y el uso de quien llama, por ejemplo: «analizar un objeto de estado y devolver campos seleccionados» o «guardar un archivo solicitado por el usuario después de aprobación explícita».

No deduzcas el límite solo a partir de un parámetro de tamaño de página proporcionado por el servidor. Los servidores pueden ignorar un parámetro, un agente puede solicitar una consulta amplia y un solo campo de texto puede dominar la respuesta. Limita el tamaño de página, la amplitud de la consulta, los bytes descodificados, los registros analizados y los bytes del resultado del agente donde cada frontera tenga sentido. Estos controles se solapan a propósito porque cada uno detecta un tipo distinto de solicitud o respuesta defectuosa.

Cuando rechaces una respuesta, registra suficientes detalles para diagnosticarla: método HTTP, host o identificador de acción, código de estado si está disponible, codificación de contenido declarada, bytes comprimidos observados, límite descodificado y si el descodificador había empezado a producir salida. No registres el cuerpo rechazado de forma predeterminada. Registrarlo puede recrear el problema de memoria y de datos sensibles en una ruta que se suponía de diagnóstico.

La aprobación humana no vuelve inofensiva una respuesta. La aprobación puede autorizar una acción con un servicio remoto, pero no predice cuántos datos devolverá ese servicio. Mantén los límites de respuesta después de la aprobación y antes de que el agente reciba datos.

La cancelación y los tiempos de espera cubren otro tipo de fallo

Un límite de tamaño descodificado detiene el crecimiento después de que el descodificador produzca suficiente salida. No detiene a un par que envía bytes dolorosamente despacio, a un descodificador que consume CPU en exceso con un flujo manipulado ni a una respuesta que nunca termina. Establece plazos para las solicitudes y asegúrate de que la cancelación cierre el cuerpo de respuesta e interrumpa el lector.

Mantén separados en métricas y errores el tiempo, los bytes comprimidos, los bytes descodificados y el número de elementos analizados. Si todos los fallos aparecen como «la solicitud falló», alguien aumentará el límite de tamaño para resolver un tiempo de espera o ampliará un tiempo de espera para resolver un fallo del analizador. Esos cambios dificultan diagnosticar incidentes y suelen ampliar la superficie de ataque.

Prueba la cancelación con un endpoint que envíe un prefijo comprimido válido y luego se detenga. El cliente debe devolver su error de tiempo de espera o cancelación sin dejar una gorutina esperando al descodificador. Después prueba un cuerpo que se expanda rápidamente más allá del límite descodificado. Esa ruta debe producir el error de tamaño con rapidez, aunque el servidor siguiera enviando bytes comprimidos.

La reutilización de conexiones requiere cuidado tras un rechazo temprano. En muchos clientes, cerrar el cuerpo basta para liberar recursos, pero es posible que la conexión no se pueda reutilizar si el cliente no ha consumido el resto de la respuesta. Es aceptable. La corrección y el uso acotado de recursos valen más que exprimir una conexión keep-alive adicional de una respuesta hostil o defectuosa.

Evita reintentar automáticamente una respuesta demasiado grande. Un error de red transitorio puede justificar un reintento dentro de una política limitada. Una respuesta que supera un límite conocido suele ser determinista. Repetirla desperdicia ancho de banda y puede multiplicar la presión sobre un proceso que ya está gestionando una acción sobredimensionada.

Los límites de análisis van después de descodificar, no en su lugar

Un analizador JSON en streaming puede evitar que almacenes todos los registros, pero no elimina el límite de bytes descodificados. Los analizadores aún necesitan búferes, las cadenas individuales pueden ser enormes y los informes de errores pueden retener fragmentos de origen. Coloca el límite de bytes delante del analizador y añade después límites de formato que coincidan con los datos que aceptas.

Para JSON, considera la profundidad máxima de anidamiento, la longitud máxima de cadena, el número máximo de registros y un esquema estricto para los campos que usará el agente. Para CSV o protocolos de líneas, fija una longitud máxima de línea y un número máximo de filas. Para XML, desactiva el procesamiento de entidades externas y establece límites del analizador cuando la biblioteca los ofrezca. Estas son reglas de análisis, mientras que el límite del cuerpo descodificado es una frontera de transporte. No obligues a una a hacerse pasar por la otra.

Valida antes de presentar. Un campo llamado instructions, command o message procedente de un servicio remoto sigue siendo contenido remoto. Su tamaño puede estar dentro del límite descodificado y aun así ser inadecuado para colocarlo en el flujo de control de un agente. Selecciona campos según el esquema y codifícalos como datos. El límite de tamaño evita una clase de fallo, pero no demuestra que el contenido de los bytes sea fiable.

Esta separación simplifica el manejo de errores. Un cuerpo que supera el límite descodificado nunca debe llegar al analizador. Un cuerpo que cabe pero tiene demasiados registros debe devolver un error de límite de análisis o de aplicación. Un cuerpo que cumple el esquema pero supera el presupuesto de presentación del agente debe reducirse mediante una regla explícita de resultado. Cada resultado indica a quien opera el sistema qué debe cambiar, si es que debe cambiar algo.

Trata el registro de auditoría como un informe de límites

Una entrada de auditoría útil indica qué intentó hacer el proceso y por qué el cliente se negó a continuar. No necesita el contenido rechazado. Guarda la identidad de la acción, el contexto de autorización, el destino, la hora de la solicitud, el estado de la respuesta cuando se conozca, la codificación, el recuento de bytes de red, el recuento de bytes descodificados o un límite inferior y el límite que puso fin a la llamada.

En un rechazo temprano, el recuento descodificado puede ser limit + 1 en vez del tamaño final real porque el cliente dejó de leer intencionadamente. Regístralo con honestidad. Afirmar que conoces el tamaño descodificado completo sugiere que consumiste precisamente el flujo que debías limitar. Un límite inferior basta para explicar la decisión.

Esto resulta especialmente útil cuando un agente repite una acción después de que un operador cambie una consulta. Puedes ver que la primera llamada superó el presupuesto de presentación o de descodificación y que la segunda tuvo éxito con una solicitud más limitada. Sin esa distinción, una llamada de herramienta fallida parece indistinguible de un problema de autenticación o de red, y la gente aplica la solución equivocada.

El rastro de actividad de Sallyport puede conservar la ruta del resultado de la acción sin entregar al agente la credencial de API. Quien llama aún debe informar de un resultado demasiado grande como un fallo acotado, en vez de convertir el registro de actividad en una segunda copia de la respuesta.

Incluye el caso sobredimensionado en el criterio de lanzamiento

No dejes las comprobaciones de descompresión como una prueba de seguridad que se ejecuta solo cuando alguien se acuerda. Incluye un archivo de prueba de límites para gzip y otro para Brotli en la suite normal de pruebas del cliente. Ejecuta las mismas comprobaciones en todas las rutas de código HTTP que puedan devolver datos a un agente, incluidas las redirecciones si tu cliente las sigue y las respuestas de error si lee sus cuerpos para diagnóstico.

Las comprobaciones deben ser concretas. Para un cuerpo por debajo del límite, espera un resultado descodificado completo y una validación correcta de la suma de comprobación. En el límite exacto, espera lo mismo. Un byte por encima del límite, espera el error de tamaño tipado, ningún objeto analizado, ningún resultado para el agente y un cuerpo de respuesta cerrado. Para una codificación malformada, espera un error de descodificación. Para una codificación no admitida, espera un error explícito de codificación no admitida antes de que empiece el análisis.

Añade una prueba para un cuerpo comprimido con tamaño de red pequeño y tamaño descodificado por encima del límite. Esa es la prueba que detecta el error original. Un cuerpo grande sin comprimir solo demuestra que funciona un limitador de bytes normal. No dice nada sobre la frontera del descodificador.

Revisa cualquier cambio que introduzca una nueva biblioteca HTTP, un nuevo ayudante práctico para obtener datos o una nueva ruta de registro de respuestas. Estos cambios suelen sortear el lector limitado cuidadosamente porque parecen inofensivos por separado. La pregunta en la revisión de código es sencilla: ¿dónde están disponibles por primera vez los bytes descodificados y qué límite rodea exactamente a ese lector?

Si la respuesta no está clara, la implementación no está lista para una persona que llama de forma autónoma. Una respuesta pequeña en la red no ha ganado ninguna confianza especial. Haz que demuestre su tamaño tras descodificarse, antes de tener la oportunidad de gastar tu memoria o la atención de tu agente.