Resumen

  • RFC 9659 obliga a que los decodificadores HTTP zstd admitan ventanas de hasta 8 MB inclusive y prohíbe a los codificadores exigir más.
  • El anuncio de capacidad, el código HTTP 200 y el nombre zstd no revelan la ventana del frame ni prueban que la representación seleccionada fue decodificada.
  • La evidencia debe conservar selección, bytes, transformaciones, variante de caché, límite efectivo del receptor, error o éxito de decodificación y aceptación de la aplicación.

El registro decía que el cliente había enviado Accept-Encoding: zstd. El servidor respondió 200 y marcó la solicitud como uso exitoso de compresión. Es posible construir un tablero completamente verde con esos dos hechos. Pero ninguno responde la pregunta decisiva: ¿qué ventana exigían los bytes seleccionados y qué ocurrió cuando el proceso receptor intentó decodificarlos?

RFC 9659 existe para eliminar una incompatibilidad concreta. En el contexto del content coding HTTP zstd, el decodificador DEBE admitir una Window_Size de hasta 8 MB inclusive, y el codificador NO DEBE producir un frame que requiera una ventana mayor. Es una obligación bilateral. El productor no puede enviar una demanda superior; el receptor que anuncia el coding no puede rebajar unilateralmente la frontera común.

La cifra está en el formato, no en la cabecera HTTP

RFC 8878 define el formato Zstandard. La ventana determina hasta qué distancia pueden apuntar las referencias a contenido ya producido y, por ello, cuánto estado puede tener que retener el decodificador. El formato permite desde 1 KB hasta unos 3,75 TB. Las ventanas grandes pueden mejorar la compresión, pero trasladan memoria al receptor.

RFC 8878 recomendaba 8 MB para HTTP sin convertir la recomendación en requisito. Un codificador podía generar una ventana mayor y un agente podía rechazarla para proteger sus recursos; ambos podían considerarse razonables y, aun así, no interoperar. RFC 9659 transforma esa recomendación en un límite verificable. El texto canónico y el XML permiten comprobar la misma norma sin depender de una paráfrasis.

La ficha del RFC Editor sitúa el documento como Informational y como actualización de RFC 8878. La consulta de erratas y el historial del Datatracker son parte de una política versionada: una organización debe poder señalar qué texto y qué estado de correcciones implementa.

La oferta, la elección y el resultado son estados distintos

RFC 9110 explica la semántica de los content codings. Accept-Encoding participa en la selección de una representación; Content-Encoding identifica la transformación aplicada. Ninguna cabecera contiene la ventana Zstandard. Tampoco indica qué binario generó el frame, si un intermediario lo sustituyó, qué presupuesto usó el proceso cliente o si la aplicación aceptó el contenido decodificado.

Por eso una métrica “porcentaje de respuestas zstd” no es una métrica de interoperabilidad. Puede contar la selección antes de la decodificación. Puede atribuir al origen bytes recomprimidos por un edge. Puede sumar respuestas pequeñas que nunca se acercan al límite y ocultar objetos grandes. Puede registrar éxito de transporte donde hubo fallo de contenido.

RFC 7694 amplía la conversación a los codings que un servidor acepta en cuerpos de solicitud. También allí, anunciar aceptación no prueba que una solicitud específica estuviera bien codificada ni que fuera procesada. El patrón sirve para ambos sentidos: oferta, coding seleccionado, bytes observados y resultado deben tener recibos diferentes.

La selección de caché puede cambiar los bytes sin cambiar la URL

RFC 9111 convierte a la caché en un participante de la entrega. Una URL puede representar varias variantes según negociación y otros campos. Un objeto comprimido antes de aplicar el límite puede seguir fresco. Dos edges pueden retener generaciones distintas. Una purga puede alcanzar una clave y no otra. Un fallback puede almacenarse bajo una identidad ambigua.

El cumplimiento no puede atribuirse sólo a la URL ni al ajuste actual del origen. Debe seguir la variante concreta: clave, generación, hash, edad, transformaciones, frame y destino. Si el origen produjo un objeto correcto y la caché sirvió otro, ambos hechos merecen sus propios registros. El error de gobierno aparece cuando un tablero los fusiona.

El registro IANA de parámetros HTTP describe zstd con una Window_Size no superior a 8 MB. Esa descripción protege el significado público del token. No inspecciona los objetos almacenados. La entrada del registro autoriza la expectativa; el frame servido confirma o refuta su cumplimiento.

La capacidad de una biblioteca no es el presupuesto de una ejecución

Un proveedor puede certificar que su biblioteca maneja 8 MB. El proceso que la integra puede tener un límite inferior, compartir memoria con otras tareas o abortar por presión. También puede completar la descompresión y fallar al analizar el documento. Un navegador puede tener diferentes generaciones desplegadas. La palabra “soporta” necesita sujeto, versión, configuración y momento.

El recibo mínimo del receptor incluye versión del agente o biblioteca, límite efectivo, ventana observada, resultado de decodificación y clasificación del error. RFC 9659 admite que lleguen frames sobredimensionados y no conformes, y que el decoder falle ante ellos. El requisito hasta 8 MB no convierte entradas inválidas en válidas ni obliga a una asignación sin límite.

Las operaciones deben separar ventana excesiva, truncamiento, corrupción, coding desconocido, fallo de memoria, error de diccionario y rechazo de aplicación. Sin esa taxonomía, activar gzip como fallback puede mejorar la tasa agregada y ocultar que una población sigue recibiendo objetos incorrectos.

Un contrato diferente no amplía éste

RFC 9842 define Compression Dictionary Transport y el coding dcz. Para ese caso, el límite puede relacionarse con el tamaño del diccionario y alcanzar 128 MB. No es el mismo contrato que zstd. La regla de dcz no autoriza frames ordinarios zstd por encima de 8 MB.

La confusión es plausible cuando una sola biblioteca implementa ambos mecanismos. Un panel puede mostrar “window size” sin exponer el coding, el diccionario o la variante. La evidencia debe conservar esos elementos, porque una abstracción interna no cambia el significado registrado en HTTP.

Del frame al resultado

En el productor, registrar binario, versión, configuración efectiva, coding, hash y cabecera de frame. En cada intermediario, registrar si pasó, decodificó, recomprimió o reemplazó. En la caché, registrar clave de variante, generación, frescura y purga. En el receptor, registrar versión, presupuesto, ventana, resultado y error. En la aplicación, registrar que el contenido fue aceptado y utilizado.

La verificación puede ser selectiva, pero debe cubrir fronteras: payloads grandes, generaciones antiguas, edges distintos, clientes restringidos, rollbacks, fallback y cambios de clave. Son señales relevantes un frame superior a 8 MB, hashes divergentes sin transformación documentada, un objeto viejo después de cambiar el límite o una distancia creciente entre respuestas negociadas y resultados completos.

La Especificación Inicial Mínima de Heng Lu sugiere una regla común pequeña: el límite de 8 MB y un comportamiento de error explícito, dejando libertad de optimización dentro de la frontera. Las capas de realidad impiden que Accept-Encoding se convierta por retórica en una decodificación. La primacía del código en ejecución devuelve la autoridad final a los bytes y al proceso reales.

RFC 9659 hace posible una expectativa compartida. La prueba empieza donde termina la cabecera.

Fuentes