Resumen

  • Cache-Status es una lista ordenada de testimonios: cada caché puede indicar si resolvió localmente la petición, por qué la reenvió, qué estado recibió, cuánto tiempo de frescura calcula, si almacenó o si agrupó solicitudes.
  • El caché decide cuándo hablar y qué parámetros opcionales revelar. Un hit puede ser una respuesta caducada, el TTL es local y una lista correcta no demuestra que todos los intermediarios aparezcan ni que sus nombres estén autenticados.
  • La organización debe conservar el campo completo y contrastarlo con Cache-Control, Age, Via, trazas, registros internos y la experiencia real, separando la entrega, la explicación y la declaración de recuperación.

La respuesta que parecía cerrar el caso

Una API vuelve a servir un perfil anterior después de una actualización. La base de datos contiene el valor correcto y el origen lo devuelve en una prueba directa. En la respuesta del cliente aparece:

Cache-Status: ReverseProxy; hit; ttl=89, Edge; hit; ttl=33

El campo parece resolver la disputa: dos cachés admiten que usaron objetos locales. Sin embargo, todavía no explica si ambos almacenaron la misma representación, cuál de ellos recibió la invalidación, si la clave separaba usuarios, si el objeto estaba autorizado para esa petición o si un intermediario ausente había modificado el mensaje.

El RFC 9211 define hit con precisión: la petición no fue reenviada por ese caché y la respuesta se obtuvo del caché. Nada más. Una respuesta caducada que se usa sin reenvío también puede ser un hit. Por eso el campo es útil, pero no es un veredicto de corrección.

El error organizativo no consiste en creer al encabezado. Consiste en pedirle una conclusión que su semántica nunca prometió.

De pistas propietarias a un lenguaje compartido

Los cachés ya emitían encabezados de diagnóstico antes del estándar. El problema era que HIT, MISS, códigos de memoria, nombres de nodo y edades cambiaban entre productos. Una herramienta podía recopilar cadenas, pero su interpretación dependía del manual o del soporte del proveedor.

Cache-Status adopta Structured Fields y organiza los relatos en una lista. El primer miembro corresponde al caché más próximo al origen y el último al más próximo al usuario. Un proxy inverso puede escribir primero, un nivel shield conservarlo y añadir su dato, y un edge completar la secuencia. La misma gramática permite automatizar análisis sin borrar las diferencias de cada nivel.

Ese orden no aparece por arte de magia. Cada caché decide si emite el campo: siempre, por configuración o cuando una petición habilita depuración. Al añadir su miembro, debería conservar los existentes. Esa obligación operativa no impide que un equipo antiguo, una pasarela o una mala configuración eliminen el historial. La lista muestra las declaraciones que llegaron al observador, no todos los cachés que necesariamente existieron.

La especificación común es mínima y valiosa: coordina palabras y tipos. La política de divulgación, la identidad, la retención y la comprobación continúan siendo decisiones locales.

Un identificador no equivale a una identidad

El miembro empieza con una cadena o token que identifica al caché. Puede ser el nombre de un producto, servicio, host, dirección IP o valor generado. La flexibilidad protege topologías y acomoda arquitecturas distintas, pero no crea una credencial.

El texto Edge-Madrid no demuestra por sí mismo que una máquina concreta, una región o una sociedad escribió el dato. Lo que sí demuestra una captura es que el mensaje observado contenía ese texto. Para atribuirlo hay que conocer la ruta, la configuración que autorizaba ese identificador y el punto de captura. Para validar la conducta interna hay que correlacionar otra superficie.

La distinción es importante cuando el proveedor controla la entrega y la primera explicación de la entrega. En operaciones normales, su testimonio directo reduce tiempo de diagnóstico. En una disputa o compromiso, una organización necesita conservar trazas, eventos de origen y observaciones propias que no dependan del mismo control.

El alcance exacto de hit

hit informa que esta petición no salió hacia el origen y que el caché aportó la respuesta. Puede incluir respuestas 304 o 206 basadas en un objeto guardado cuando no hubo reenvío. También puede incluir una respuesta caducada servida bajo una regla válida sin contactar al origen.

Las condiciones para almacenar, seleccionar, reutilizar, validar o servir contenido caducado se encuentran en el RFC 9111, Cache-Control, Expires, validadores, Vary y extensiones como stale-if-error. Cache-Status llega después de esa decisión. No autoriza lo que las reglas prohíben.

Conviene separar cuatro planos. La norma define qué está permitido. La configuración materializa una política. El campo describe parte de la ejecución. La aplicación y el usuario determinan si la representación es correcta. Un hit sólo cubre una pequeña parte del tercer plano.

Este límite también evita una falsa inocencia. Si la clave omitió el tenant y el caché aplicó exactamente su configuración, hit puede ser veraz mientras el sistema filtra información. Una ejecución fiel no corrige una política peligrosa.

fwd cuenta por qué hubo que avanzar

Un MISS genérico mezcla decisiones que requieren respuestas diferentes. Cache-Status ofrece motivos más específicos.

uri-miss indica que no había una respuesta para esa URI. vary-miss indica que existía una coincidencia de URI, pero no una variante compatible con los campos de la petición. request muestra que había una respuesta fresca seleccionable, aunque la semántica de la petición impedía usarla. stale marca una selección caducada que obligó a reenviar. partial señala rangos incompletos. method y bypass describen la semántica del método o una exclusión configurada. miss queda para implementaciones que no pueden precisar.

Un aumento de uri-miss puede seguir a un cambio de rutas. vary-miss puede revelar una nueva lengua, codificación o cabecera de negociación. request puede provenir de clientes que exigen revalidar. bypass puede ser la evidencia de que una exclusión funciona, no de que el caché esté vacío.

Si la plataforma genera detalles y el panel vuelve a unirlos bajo MISS, la organización renuncia a la información que el estándar hizo interoperable.

Ocho parámetros, ocho fronteras

fwd-status registra el código devuelto por el siguiente salto. Cuando el caché revalida un objeto y recibe 304, puede responder 200 al cliente y conservar la pista fwd-status=304. La pista demuestra un intercambio condicional, no que el dato de negocio fuera el correcto.

ttl es el tiempo de frescura restante calculado por el caché cerca del envío de cabeceras. Puede incorporar heurística o configuración local y ser negativo. No es un vencimiento universal. Tampoco reemplaza Age, que estima el tiempo desde que el origen generó o validó la respuesta a través de residencia y transporte.

stored afirma que el caché guardó una respuesta reenviada. No garantiza residencia futura ni selección posterior. collapsed indica que varias peticiones compartieron un reenvío; protege al origen de estampidas, pero amplifica el efecto de una sola respuesta sobre muchos usuarios.

key expone una representación, posiblemente específica de la implementación, de la clave usada. Ayuda a diagnosticar consultas, Vary, idiomas y separación entre clientes. También puede revelar transformaciones aprovechables para envenenar el caché. detail acepta estados locales cuyo significado no se puede trasladar automáticamente entre productos.

Salvo reglas contextuales, los parámetros son opcionales. Ausencia significa que el mensaje no formula esa afirmación. Convertir ausencia en falso elimina incertidumbre mediante una invención.

No es lo mismo controlar que informar

Cache-Control dirige almacenamiento y reutilización. Age aporta una estimación temporal. Via enumera receptores intermedios y protocolos. Proxy-Status explica tratamiento o errores del proxy. Cache-Status describe decisiones de caché. Campos como No-Vary-Search pueden declarar equivalencias de componentes de consulta para formar claves.

Estas superficies se relacionan, pero ninguna hereda la autoridad de otra. Un hit posterior a una regla de equivalencia no demuestra que la equivalencia fuese segura para la aplicación. Un key visible no demuestra que incluya todas las dimensiones necesarias. Un TTL positivo no anula una directiva incorrecta.

La evidencia responsable conserva la configuración que produjo la clave, su versión, una huella segura de la clave efectiva y pruebas de idioma, autenticación, tenant y personalización. Así puede detectarse una decisión técnicamente consistente que violó el límite de negocio.

La firma no viene incluida

RFC 9211 no define firma ni MAC para sus miembros. El campo desnudo no ofrece por sí solo integridad o autenticación. Las HTTP Message Signatures pueden cubrir campos seleccionados, siempre que la aplicación defina componentes obligatorios, claves, algoritmos, tiempos, autoridad del firmante y tratamiento de errores.

El perfil debe incluir explícitamente Cache-Status. También debe resolver dónde se firma en una ruta con varios cachés, porque un nivel posterior puede añadir miembros después de la firma anterior. Incluso una firma válida prueba la relación entre un firmante y los componentes cubiertos; no observa la memoria del caché para confirmar la veracidad del hit.

No todos los servicios necesitan esa complejidad. Capturas autenticadas, acceso de depuración, trazas compartidas y eventos conservados en un sistema separado pueden dar la garantía adecuada. Lo obligatorio es describir la garantía real sin apropiarse de propiedades que no existen.

La depuración también filtra información

RFC 9211 advierte que Cache-Status puede facilitar el sondeo del caché y la inferencia de actividad de usuarios que lo comparten. Saber si una respuesta está guardada puede ayudar a ataques temporales. Exponer la clave puede revelar transformaciones y ayudar al envenenamiento. Ofuscarla no elimina necesariamente el riesgo.

El operador puede omitir el campo, enviarlo sólo a clientes autorizados o restringir los parámetros sensibles. Por tanto, la emisión es una decisión de acceso.

Un perfil público mínimo puede publicar identificadores seudónimos y el resultado principal. Un perfil autenticado puede añadir TTL, estado aguas arriba, almacenamiento, agrupación y una clave segura. Un sistema sensible puede exportar la mayor riqueza a una plataforma interna independiente y no revelarla en Internet.

La meta no es máxima transparencia ni silencio total. Es entregar a cada audiencia la evidencia necesaria, sin crear un oráculo para atacantes ni un monopolio de información para el proveedor.

Cómo reconstruir un incidente

Primero se conserva la respuesta completa en el punto observado: método, URI, campos relevantes, estado, Date, Age, Cache-Control, Expires, ETag, Last-Modified, Vary, Via, Proxy-Status y el valor ordenado de Cache-Status.

Después se vincula cada miembro con el nivel, versión y época de configuración esperados. Si la clave es necesaria, se usa una huella con secreto o una representación autorizada, no una copia cruda en un canal amplio.

Luego se exige una segunda observación. Un hit debe tener evento de búsqueda y objeto. fwd=stale; fwd-status=304 debe tener petición condicional. Una agrupación debe revelar grupo y número de esperas. stored debe coincidir con un evento, aceptando que después puede haber expulsión.

Al final se compara la representación con lo que correspondía a ese usuario, idioma y tenant. Tras purga o cambio, se prueba la ruta del usuario. Que HIT pase a MISS sólo demuestra otra decisión de caché.

La disciplina de las pruebas

El equipo debe poder producir un hit y demostrar que no hubo tráfico aguas arriba; distinguir uri-miss y vary-miss; forzar revalidación; probar servicio caducado permitido y TTL negativo; agrupar una ráfaga y reconciliar esperas con peticiones de origen.

También debe verificar la divulgación: ninguna clave sensible en público, sólo parámetros aprobados con depuración autenticada, orden estable tras actualizar edge, shield o pasarela, y extensiones desconocidas conservadas sin significado inventado. Si hay firmas, modificar un componente cubierto debe fallar y el perfil debe demostrar que cubre Cache-Status.

El registro IANA de Cache-Status coordina nombres y tipos; el registro de campos HTTP lo mantiene como campo permanente de tipo List. Eso prueba una convención compartida, no el comportamiento de una flota. Sólo la ejecución observada cierra esa distancia.

Registro de evidencias