Problema y contexto
Una página pasa a través de cachés de navegador, CDN y proxy inverso de origen. Los usuarios reportan solicitudes lentas ocasionales, y debes usar campos de respuesta estandarizados para identificar qué capa falló, revalidó o colapsó solicitudes. Diseña el plan con RFC 9211 y aborda los riesgos de privacidad y envenenamiento de caché en producción.
Qué evalúa el entrevistador
La clave es que Cache-Status es una lista de campos estructurados; cada miembro representa una caché que manejó la solicitud, ordenada desde la caché más cercana al origen hasta la más cercana al usuario. Explica hit frente a fwd, los motivos de reenvío y ttl, además de la autorización y redacción para diagnósticos.
Preguntas aclaratorias para hacer primero
Topología y propiedad de la caché
Pregunta si el navegador añade el campo, si cada capa preserva los valores aguas arriba y qué equipos pueden cambiar la configuración de la CDN y del proxy inverso. Sin un orden, la lista no puede interpretarse de manera confiable.
Muestreo de depuración y datos confidenciales
Pregunta si los diagnósticos están habilitados solo para solicitudes internas, la tasa de muestreo y la retención de registros. Las claves de caché, los identificadores de inquilinos y las respuestas personalizadas pueden ser confidenciales y no deben devolverse a todos los clientes.
Objetivos de frescura y consistencia
Confirma Cache-Control, validadores, ventanas de datos obsoletos toleradas y requisitos de consistencia del negocio. Un ttl negativo significa que esa capa calculó obsolescencia; no demuestra por sí solo que se hayan entregado bytes obsoletos.
Marco de respuesta de 30 segundos
“Cada caché añade su propio miembro Cache-Status mientras preserva la lista, la cual leo desde el origen hacia el usuario. hit significa que no se necesitó un siguiente salto; fwd lleva motivos como uri-miss, vary-miss o stale, y fwd-status=304 identifica la revalidación. Solo la depuración interna autorizada devuelve detalles o claves; la salida de producción se redacta para evitar la filtración de inquilinos y pistas para envenenamiento de caché.”
Pasos detallados de la solución
Paso 1: Analizar el campo estructurado
Analiza Cache-Status como una lista de RFC 8941 y lee el identificador y los parámetros de cada miembro. No uses comprobaciones de subcadenas: los miembros pueden contener cadenas entrecomilladas, parámetros reordenados y capas repetidas.
Paso 2: Definir reglas de adición y ordenamiento
Cuando una capa ve un campo existente, añade su miembro en lugar de sobrescribir la evidencia de aguas arriba. La caché más cercana al origen aparece primero y la más cercana al usuario al final; una capa faltante se registra como una brecha en la topología, no se asume.
Paso 3: Interpretar aciertos y reenvíos
hit significa que la capa satisfizo la solicitud a partir de datos almacenados. fwd=uri-miss significa que no hubo URI coincidente, vary-miss significa que la selección Vary falló y stale significa que la respuesta seleccionada estaba obsoleta. fwd-status tiene sentido en el reenvío y distingue una validación 304 de otra respuesta.
Paso 4: Correlacionar TTL, almacenamiento y colapso
ttl es la estimación de frescura restante de la capa y puede ser negativo; stored indica si se almacenó una respuesta reenviada; collapsed indica si las solicitudes compartieron un único reenvío. Correlaciona estos campos con los IDs de solicitud, el tiempo de origen y los códigos de estado para explicar la latencia de cola.
Paso 5: Manejar personalización y claves de caché
Para respuestas autenticadas, específicas de inquilinos o con cookies, primero verifica la capacidad de almacenamiento en caché según RFC 9111. Las respuestas de producción exponen únicamente la identidad de la caché, el tipo de acierto y un TTL aproximado; key y los detalles permanecen en un canal de depuración controlado con los fragmentos controlados por el usuario eliminados.
Paso 6: Construir una política de muestreo segura
Habilita los diagnósticos mediante un campo de solicitud interno, autorización de corta duración o configuración perimetral, y mantén la salida detallada fuera de la ruta pública por defecto. Analiza y protege los registros para que los atacantes no puedan inferir comportamientos de temporización ni descubrir claves de caché.
Paso 7: Verificar de extremo a extremo
Crea casos de URI-miss, Vary-miss, validación obsoleta, colapso de solicitudes y aciertos multicapa. Verifica el orden de la lista, fwd-status, el signo del TTL y la preservación de los miembros de aguas arriba. Compara respuestas, registros de caché y trazas de origen para garantizar que la observabilidad no altere la semántica de almacenamiento en caché.
Ejemplo de respuesta de alta calidad
Haría que el navegador, la CDN y el proxy inverso añadan Cache-Status y lo analizaría con un analizador de campos estructurados. Primero clasificaría cada capa como hit o fwd, y luego usaría el motivo de reenvío, fwd-status, ttl, stored y collapsed para explicar las solicitudes lentas. Solo la depuración interna expondría key o detail; las respuestas públicas permanecerían redactadas. Las pruebas cubren URI miss, Vary miss, 304 obsoleto, colapso de solicitudes y ordenamiento multicapa.
Errores comunes
- Error: Tratar al último miembro como el único resultado. → Por qué: La lista registra toda la cadena de caché. → Solución: Explicar cada miembro desde el origen hasta el usuario.
- Error: Asumir que hit siempre significa fresco. → Por qué: Se puede servir una respuesta obsoleta mediante una política local explícita. → Solución: Combinar ttl con Cache-Control y el estado de reenvío.
- Error: Sobrescribir el Cache-Status de aguas arriba. → Por qué: Se pierde la evidencia previa. → Solución: Preservar y añadir un miembro.
- Error: Devolver key y detail de forma pública. → Por qué: Pueden revelar pistas sobre inquilinos, temporización o envenenamiento. → Solución: Restringir y redactar en un canal de depuración.
Preguntas y respuestas de seguimiento
Pregunta de seguimiento 1: ¿Cómo se relacionan hit y la validación 304?
La reutilización sin contactar al siguiente salto es un acierto (hit). Si la caché debe validar con el siguiente salto, utiliza fwd; fwd-status=304 puede mostrar que el siguiente salto validó la representación almacenada.
Pregunta de seguimiento 2: ¿Se pueden concatenar directamente múltiples líneas de campo Cache-Status?
La combinación de campos HTTP trata los campos con el mismo nombre como una sola lista, pero las implementaciones deben usar un analizador RFC 8941 para comas, comillas y parámetros en lugar de una simple concatenación de cadenas.
Pregunta de seguimiento 3: ¿Un TTL negativo demuestra que llegaron bytes obsoletos al usuario?
No. Indica que esa capa calculó que la respuesta era obsoleta. La capa puede revalidarla o servirla bajo una política de obsolescencia explícitamente permitida; inspecciona las directivas de reenvío y respuesta.
Pregunta de seguimiento 4: ¿Cómo depuras una lentitud que afecta solo a algunos usuarios?
Compara miembros, selección de Vary, TTL y tasas de colapso entre nodos, y luego correlaciona geografía, cookies y campos de solicitud. Un vary-miss aislado en una sola capa sugiere una desviación en la construcción de claves o un desajuste de configuración.