Resumen

  • Cache-Status es una lista estructurada y ordenada. Cada miembro habla por una caché; la más cercana al origen aparece primero y la más próxima al usuario aparece al final.
  • Los términos tienen alcance limitado. hit no certifica frescura, ttl puede ser negativo, y stored o collapsed solo se interpretan en un miembro que incluya fwd.
  • La operación responsable conserva el orden y la captura original, separa el identificador declarado de la identidad comprobada y limita la divulgación según el destinatario.

La ruta no cabe en una casilla

Supongamos que una petición pasa por una caché del proveedor, una pasarela corporativa y el navegador. La primera puede haber reenviado la solicitud por falta de una respuesta utilizable. La segunda puede guardar lo recibido. El navegador, más tarde, puede contestar sin reenviar nada. Decir simplemente “hit” sobre toda la ruta confunde tres decisiones compatibles.

RFC 9211 resuelve el problema con una lista de Structured Fields. Cada caché que participa añade un miembro y debe conservar los miembros anteriores. El orden tiene significado: empieza del lado del origen y avanza hacia el usuario. El resultado no es una votación ni una reducción; es una secuencia de afirmaciones locales.

Pero la secuencia tampoco promete una radiografía completa. La caché decide si emite Cache-Status siempre, solo bajo configuración o cuando una petición de depuración lo solicita. También puede omitir parámetros. Un intermediario que no aparece pudo haber intervenido. Por eso, la ausencia de un miembro no demuestra ausencia de caché.

El registro operativo debe describir la evidencia con modestia: “esto es lo que llegó a este punto de observación en esta respuesta”. Convertirlo en “esta fue toda la cadena” añade una conclusión que el protocolo no entrega.

Identificar no es autenticar

Cada miembro se abre con un identificador de tipo String o Token. Puede ser un producto, un servicio, un nombre de host, una dirección IP o una cadena generada. La variedad permite evitar una exposición obligatoria de la topología.

Esa etiqueta procede del mismo componente que formula la declaración. Por sí sola, no prueba que el componente sea quien dice ser. En una red administrada puede existir una asociación fuerte gracias a controles de despliegue, rutas protegidas o registros internos. En Internet abierto, el mismo texto puede carecer de ese respaldo.

Conviene guardar por separado el valor declarado, el punto de captura, la prueba externa que lo vincula con un emisor y el nivel de confianza del analista. Si todo se transforma en un campo “trusted=true”, se pierde la posibilidad de revisar por qué se confió.

RFC 9421 proporciona un marco para firmas de mensajes HTTP. Puede formar parte de una política de integridad independiente si se definen claves, componentes cubiertos y transformaciones. No implica que Cache-Status esté firmado por defecto, ni resuelve automáticamente la confianza en cada caché que contribuyó a la lista.

Qué dice realmente hit

hit=true informa de que esa caché no reenvió la petición y obtuvo la respuesta de su almacenamiento. La definición no exige que la respuesta estuviera fresca. Si las reglas permiten servir una respuesta caducada sin contactar aguas arriba, sigue siendo un hit.

También hay respuestas almacenadas que no cuentan como hit. Si fue necesario reenviar la petición para validarlas, la actuación pertenece a la rama fwd. Los dos parámetros son excluyentes porque el dato relevante es si aquella petición salió o no de la caché.

Esta delimitación impide usar una única métrica para objetivos diferentes. Reducir carga en el origen, mantener frescura, evitar mezcla entre usuarios y disminuir latencia son preguntas distintas. El conteo de hit puede contribuir a una, pero no sustituye los controles de caché, el contexto de la solicitud ni la prueba de reutilización segura.

Los cuadros de mando deberían conservar el miembro que produjo el dato. Sumar todos los hit de una cadena como si fueran eventos equivalentes puede contar una misma respuesta varias veces y, además, esconder qué capa tomó la decisión.

fwd y sus parámetros dependientes

Cuando la solicitud se reenvía, fwd indica el motivo más específico conocido por la caché: una omisión, una regla de método, una URI distinta, un miss, contenido obsoleto o validación, entre otras categorías definidas. La clasificación comparte un idioma diagnóstico sin obligar a revelar toda la lógica interna.

fwd-status solo tiene significado junto a fwd. Si falta, se toma como implícito el estado enviado al cliente. stored indica si se guardó la respuesta procedente del reenvío. collapsed distingue si la petición se unió con éxito a otra ya en curso o provocó una nueva salida. stored y collapsed tampoco son atributos generales de cualquier miembro.

Un esquema tabular ingenuo crea columnas para todos los parámetros y convierte los huecos en false. Así mezcla “no aplicable”, “no divulgado” y “no observado”. La representación fiel mantiene cada conjunto de parámetros ligado a su miembro y registra las precondiciones semánticas.

La captura bruta también debe conservarse. Cache-Status usa la sintaxis formal de Structured Fields, no una lista improvisada de fragmentos separados por comas. RFC 9211 se redactó sobre RFC 8941; RFC 9651 sustituyó posteriormente esa especificación general. La evolución de la familia no autoriza un parser casual ni una reinterpretación retrospectiva.

ttl no sincroniza las cachés

ttl es la vida de frescura restante calculada por esa caché cerca del momento en que escribe el campo. Puede incorporar reglas de edad, heurísticas y configuración local. Un número negativo es válido cuando la respuesta está obsoleta.

Por ello, los ttl de varios miembros no conforman una cronología común. Quizá se refieran a objetos almacenados en momentos distintos o a políticas distintas. Restarlos para estimar el tiempo de red, o escoger uno como “TTL global”, carece de fundamento.

Sí pueden responder preguntas con procedencia. ¿Una caché sirve de forma habitual sin reenviar cuando declara ttl negativo? ¿Cambió el patrón al modificar una heurística? ¿Aparece validación pese a un ttl positivo? Cada investigación se formula alrededor de un miembro y se contrasta con su configuración.

La hora y el lugar de observación forman parte del dato. Una segunda petición puede tomar otra ruta, encontrar otra versión o activar otra política de emisión. Cache-Status describe una respuesta concreta, no una propiedad eterna de la URL.

La transparencia también abre una superficie de ataque

key ofrece una representación específica de la implementación de la clave de caché. detail permite datos locales y su significado puede variar entre emisores. Cuando una noción necesita interoperabilidad, RFC 9211 orienta hacia un parámetro registrado o un campo separado.

IANA mantiene el registro de parámetros Cache-Status bajo Expert Review. La arquitectura permite promover conceptos genéricos y mantener las extensiones de proveedor con un nombre acotado. La revisión coordina semántica; no decide quién debe ver el parámetro en una respuesta real.

La distinción es esencial porque key, nombres de host y detalles de encaminamiento pueden ayudar a reconocer componentes o preparar un envenenamiento de caché. El campo también puede facilitar inferencias sobre actividad de usuarios o ataques temporales. RFC 9211 recalca que ofuscar una clave no elimina por sí solo ese peligro.

La respuesta razonable no es publicar todo ni apagar todo. Una salida pública puede limitarse a categorías generales. Una sesión de diagnóstico autenticada puede recibir más información. Los componentes de la clave y los detalles de tenencia pueden quedar en registros protegidos. La caché aplica la decisión cerca del riesgo que conoce.

Un procedimiento que conserva la evidencia

Primero se guarda el campo exacto con hora, contexto de petición y punto de captura. Después se analiza como lista estructurada ordenada. Cada miembro se almacena como declaración separada; nunca se desplazan parámetros hacia una entidad global.

Luego se aplican las condiciones: hit frente a fwd, parámetros dependientes de fwd, ttl local y detail local. La evaluación de confianza se añade aparte. Finalmente, una regla de divulgación decide qué versión puede cruzar cada frontera.

El informe resultante puede ser incómodo pero honesto: “Un miembro que se identifica como borde regional declaró miss y almacenamiento; otro miembro declaró hit. El primero está vinculado a infraestructura gestionada; no hay autenticación independiente del segundo.” Esa frase puede auditarse y corregirse. “Veredicto: hit” no.

Fuentes