Resumen

  • RFC 9111 recomienda enviar must-understand junto con no-store. Una caché que desconoce la primera directiva debe ignorarla, pero todavía sabe obedecer la segunda.
  • «Entender» un estado no significa leer su número. Exige reconocerlo y aplicar todo el comportamiento de caché que su especificación establece.
  • La excepción a no-store elimina una sola barrera. No concede almacenamiento automático, reutilización, privacidad ni autorización; las demás condiciones de HTTP siguen vigentes.

Una línea para dos edades del protocolo

Imaginemos dos intermediarios frente a Cache-Control: must-understand, no-store.

El primero fue desplegado antes de que existiera must-understand. Las extensiones de Cache-Control están diseñadas para que una directiva no reconocida se ignore. Por tanto, ese intermediario pasa por alto la novedad, encuentra no-store y no guarda la respuesta.

El segundo sí implementa la nueva directiva. Aun así no obtiene una licencia inmediata. Debe reconocer el código de estado de la respuesta y cumplir todos los requisitos de almacenamiento que la definición de ese estado impone. Solo entonces RFC 9111 dice que debería ignorar el no-store acompañante y evaluar el resto de las reglas.

La elegancia reside en que ambas decisiones son coherentes. El origen no necesita un inventario perfecto de cada caché que encontrará. La caché vieja recibe una instrucción conservadora ya conocida. La nueva puede ampliar su conducta con una prueba local. El despliegue no espera una actualización simultánea de toda la red.

El error editorial consiste en citar únicamente must-understand. El nombre parece una orden universal, pero el receptor que no lo implementa está obligado a ignorarlo. Si no viaja con no-store, la vieja caché no recibe el retroceso previsto. La unidad real del cambio son dos directivas y una condición verificable.

El conocimiento no es una etiqueta de producto

RFC 9111 define con precisión cuándo una caché «entiende» un código de estado: tiene que reconocerlo e implementar todo el comportamiento relacionado con caché que esté especificado para él.

Hay varias capacidades más débiles. Un analizador puede aceptar tres dígitos. Una biblioteca puede mostrar un nombre. Un cliente puede tratar un código desconocido como otro de su misma clase. Ninguna prueba que el motor respete la regla particular de almacenamiento.

RFC 6585 ofrece un contraste práctico: ordena no almacenar las respuestas 428, 429, 431 y 511. RFC 7538 define 308 como almacenable por defecto, salvo que la semántica del método o controles explícitos indiquen otra cosa. No son una lista exhaustiva; muestran que dos estados pueden exigir decisiones opuestas.

Una caché que muestra correctamente «429 Too Many Requests» pero guarda la respuesta como una entrada ordinaria reconoce el estado sin entenderlo en el sentido de RFC 9111. Asimismo, una prueba que solo verifica que el token must-understand se analiza confirma sintaxis, no conducta.

Un registro operativo debería separar cinco hechos: el código observado; su reconocimiento; la implementación de sus requisitos de caché; el soporte de la directiva; y el resultado de todas las reglas ordinarias que todavía quedan. Reducirlos a una marca de «compatible» convierte una condición técnica en una declaración de confianza imposible de auditar.

El freno antiguo hace posible la vía nueva

HTTP exige ignorar las directivas de caché desconocidas para que las extensiones no rompan software desplegado. RFC 9111 explica el patrón de las extensiones conductuales: se envía una directiva nueva junto a otra antigua; quien no conoce la primera adopta el comportamiento de la segunda, y quien sí la conoce entiende cómo modifica la regla anterior.

En esta pareja, no-store es el freno antiguo. No contradice a must-understand: hace que el resultado por defecto sea prudente. La caché nueva puede levantarlo en la circunstancia exacta que la norma describe.

Omitir el freno importa. Una caché antigua ignorará la única directiva que ve y quizá almacene si otras reglas se lo permiten. Puede decidir no hacerlo por motivos propios, pero ya no gracias a la protección de transición diseñada en RFC 9111.

La norma usa SHOULD tanto para añadir no-store como para que la caché cualificada lo ignore. Es una recomendación normativa, no una decoración, y tampoco un mandato ciego. Alejarse de ella exige una razón técnica consciente. La brevedad del encabezado no sustituye un análisis de compatibilidad.

Quitar una prohibición no satisface las demás reglas

La expresión «ignorar no-store» suele transformarse, sin justificación, en «almacenar». En realidad, la excepción resta un impedimento y nada más.

La sección 3 de RFC 9111 conserva otras condiciones: el método debe permitir almacenamiento; el estado ha de ser final; ciertos estados requieren comprensión; pueden intervenir Authorization y las restricciones de cachés compartidas; private sigue siendo vinculante; y debe existir una base explícita o definida por el estado para considerar almacenable la respuesta.

Después llega la reutilización. Una entrada almacenada solo puede responder a otra solicitud cuando coincide correctamente y está fresca, validada o autorizada a servirse caducada. must-understand no crea frescura, no valida el objeto y no arregla una clave que mezcle usuarios.

Por eso el dato útil no es must_understand=true. La traza debe nombrar el estado y su referencia, la evidencia de implementación, las dos directivas recibidas, las otras comprobaciones, la decisión de almacenamiento y la eventual reutilización. Así se conserva la cadena causal en vez de un resultado binario.

Un registro común no certifica una instalación

Los registros de IANA enumeran directivas de caché y códigos de estado con sus documentos de referencia. Permiten que todos usen el mismo nombre y localicen la especificación correcta. No dicen qué software la ha implementado.

La presencia de must-understand en la tabla no convierte un binario en conforme. Un estado registrado tampoco demuestra que un módulo de caché conozca sus reglas. Incluso un ensayo superado para un código no autoriza a asumir soporte para otro introducido más tarde.

La capacidad necesita su propio expediente: versión, módulo habilitado, requisitos verificados y resultados. El encabezado ofrece un punto interoperable para consultar esa capacidad; no la fabrica.

El apéndice de RFC 9111 señala que must-understand fue incorporado para que las cachés no tengan que comprender la semántica de nuevos estados salvo cuando la directiva aparece. El origen puede señalar que las reglas especiales importan en esa respuesta. No puede proclamar competente a una caché remota desconocida.

No es un sello de privacidad

RFC 9111 advierte que no-store no basta para garantizar privacidad. Una caché maliciosa o comprometida puede desobedecer, y la red puede quedar expuesta a escucha. La pareja no amplía ese compromiso.

Tampoco decide quién está autorizado, si una caché compartida aísla identidades, si el transporte es confidencial ni cómo se protege un disco. Usar el encabezado como etiqueta de clasificación sustituiría controles reales por una expectativa.

Este análisis no mide adopción, conformidad de proveedores, fugas ni incidentes. Los recorridos descritos son hipótesis derivadas de textos normativos.

Fuentes y límites de la evidencia

Los registros y las erratas son instantáneas a la fecha de investigación. Las fuentes establecen reglas y una lectura de gobernanza, no soporte universal en productos.