Resumen

  • Un miembro Cache-Status describe cómo trató la petición la caché que informa; sus parámetros hit y fwd tienen un significado local definido.
  • Cada caché decide cuándo emitir el campo, los parámetros son opcionales y la divulgación puede limitarse, por lo que una lista corta no prueba que no existieran otras cachés o decisiones.

Imaginemos una revisión de incidente expresamente hipotética. La respuesta contiene Cache-Status: edge; hit. El panel dibuja una única caja verde, declara que hubo una sola caché en la entrega y registra que ningún sistema anterior participó. El miembro puede ser veraz: la caché de borde satisfizo esta petición desde almacenamiento sin reenviarla. Sin embargo, una caché más próxima al origen pudo haber suministrado la respuesta almacenada en un intercambio anterior y omitir su propio campo. La respuesta explica lo que hizo el borde ahora; no reconstruye todos los sucesos que pusieron allí el objeto.

La RFC 9211 asigna a Cache-Status una función precisa y limitada. Cada miembro de la lista representa una caché que trató la petición y decidió informar. Si sobreviven varios miembros, aparecen desde la caché más cercana al origen hasta la más cercana al usuario. La caché que añade un miembro debería conservar los valores ya presentes. Estas reglas convierten el campo en una herramienta valiosa para depurar la cadena visible.

La lista no tiene por qué ser exhaustiva. La propia especificación indica que las cachés deciden cuándo es apropiado añadir el campo. Una instalación puede hacerlo siempre; otra, solo mediante configuración o cuando la petición activa un modo de diagnóstico. La política de seguridad también puede justificar la omisión o una divulgación selectiva, porque el estado de caché, la actividad y la clave pueden facilitar ataques. La ausencia de un miembro significa «no informado aquí», no necesariamente «no había una caché aquí».

Los parámetros tienen el mismo alcance local. hit significa que la caché que añadió el miembro no reenvió esta petición y obtuvo la respuesta de su caché. fwd significa que envió la petición hacia el origen y puede explicar el motivo con valores como uri-miss, vary-miss, stale o request. Son hechos operativos útiles, no simples colores para un cuadro de mando.

Pero la verdad local no equivale a una topología completa. fwd-status informa del estado devuelto por el siguiente salto, que puede ser otro intermediario y no el origen. El identificador de caché puede ser el producto, el host, una dirección o una cadena generada. Los detalles opcionales dependen de la implantación. Sin configuración ni contexto del punto de observación, etiquetas iguales no garantizan el mismo papel y etiquetas distintas no prueban infraestructuras independientes.

El tiempo también delimita la prueba. Cache-Status describe la petición y la respuesta correspondientes. Un hit no cuenta cuándo ni por qué cadena se adquirió la respuesta almacenada. No prueba que el origen nunca haya sido contactado durante la vida del objeto. Tampoco explica cómo se trató otra petición con diferentes directivas, credenciales, valores Vary o condiciones de frescura. La RFC 9111 hace que esas decisiones sean específicas de cada petición.

Esta separación protege la atribución de incidentes. Un fwd=stale; fwd-status=304 visible respalda lo que la caché que añadió el miembro recibió de su siguiente salto. No basta para afirmar que ese salto era el origen, que todas las cachés añadieron su miembro o que en otros puntos ocurrió lo mismo. Un campo escaso puede reflejar una ruta corta, una política de divulgación, una limitación técnica o una combinación.

Utilice un recibo de observación de caché. Es un control operativo editorial, no un objeto de protocolo definido por el IETF. Conserve los bytes del campo y vincúlelos con la petición, la respuesta, el punto y la hora de observación. Para cada salto esperado, registre la configuración de emisión, el mapa de identificadores, los parámetros mostrados u ocultos, la traza de reenvío, la identidad del siguiente salto y los registros que corroboran el recorrido. Marque los huecos como desconocidos en vez de convertir el silencio en ausencia.

El recibo no sustituye a Cache-Status; mantiene el campo dentro de su alcance probatorio. Un hit informado sigue demostrando un hit local. Un reenvío informado sigue demostrando esa acción por parte de esa caché. El registro adicional responde a la pregunta mayor: ¿qué parte de la cadena podía informar, cuál informó y qué evidencia independiente cierra los huecos?

Fuentes