Resumen

  • Cache-Groups vincula respuestas almacenadas solo cuando una misma caché conserva la cadena exacta y ambas pertenecen al mismo origen.
  • Cache-Group-Invalidation expresa una posibilidad local tras una petición no segura; no obliga, no se encadena y no coordina otras cachés.

Imaginemos una operación que modifica un catálogo. Cambian el detalle, la lista y un resumen, aunque cada recurso tenga una URI y una clave de caché distintas. RFC 9875 permite que el origen declare esa relación sin fingir que las tres respuestas son la misma representación.

El campo Cache-Groups es una lista de cadenas definida con Structured Fields. La cadena es opaca para la caché: puede compararla, pero no interpretar su sintaxis como una jerarquía ni extraer autoridad de su nombre. El orden no importa y se ignoran los parámetros desconocidos. La implementación debe admitir al menos 32 grupos en un campo y 32 caracteres por miembro, dentro de los límites generales de los campos HTTP.

La igualdad requiere tres condiciones simultáneas: las dos respuestas están almacenadas en la misma caché, contienen exactamente la misma cadena con distinción entre mayúsculas y minúsculas y comparten origen URI. Reutilizar la palabra catalogo en otro origen no crea una relación. Encontrar la misma palabra en otra caché tampoco crea memoria compartida.

El campo Cache-Group-Invalidation aparece en una respuesta a una petición que puede cambiar estado. Enumera grupos que la caché receptora puede invalidar. Si llega en la respuesta a una petición segura como GET, debe ignorarse. El método es parte de la prueba; guardar solamente el valor del encabezado pierde una condición de procesamiento.

La norma dice MAY, no MUST. Una caché puede ampliar la invalidación a miembros del grupo y puede actuar sobre el campo recibido después de POST, PUT o DELETE, pero RFC 9875 no impone esa conducta a todos los intermediarios. RFC 9213 permite dirigir controles a clases de caché y puede endurecer la regla. Ese perfil adicional debe quedar identificado en la configuración y en el recibo.

La invalidación local tampoco informa por sí sola de la consecuencia física. Conforme a RFC 9111, una caché puede eliminar la respuesta almacenada o marcarla como inválida y exigir validación antes de reutilizarla. En el segundo caso los bytes pueden seguir presentes. La siguiente solicitud aún debe validarlos, reemplazarlos o fallar.

La relación no se expande como un grafo. Si A comparte un grupo con B y B comparte otro con C, invalidar A no hace que el efecto atraviese B hasta C. RFC 9875 prohíbe ese encadenamiento. Lo que cuenta es el conjunto de miembros que esa caché tenía en ese instante.

Tampoco existe una orden de flota. El documento limita el mecanismo a una sola caché y a respuestas de un solo origen. Excluye expresamente la sincronización entre cachés de una jerarquía o una malla. Un punto de presencia puede recibir el cambio mientras otro sirve una copia que nunca vio el mensaje; ambos pueden cumplir su política local.

Por eso el control necesita una secuencia de evidencias. Primero, el cambio de estado en el origen y la autoridad para emitir los campos. Después, método, respuesta y ruta; recepción por cada intermediario; soporte y versión; política local; miembros presentes; decisión de invalidación; eliminación o marcado; validación o llenado posterior; y, finalmente, un canario de aplicación en cada ruta relevante.

En alojamientos compartidos, la autoridad de emisión no es un detalle. RFC 9875 advierte que una parte podría agrupar recursos con los de otra parte del mismo origen o enviar señales con efectos ajenos. La plataforma debe controlar quién puede introducir o conservar esos campos, con separación por origen y arrendatario.

El registro de campos HTTP de IANA incluye ambos nombres como listas permanentes. Eso prueba una denominación normalizada y una referencia, no que un producto los implemente, una ruta los conserve o una persona haya recibido contenido actualizado.

Fuentes