Resumen

  • RFC 9111 obliga a una caché que recibe una respuesta sin error a una petición no segura a invalidar el URI objetivo, pero la regla actúa en las cachés atravesadas por esa petición.
  • Afirmar una purga global exige pruebas adicionales sobre cobertura de rutas, URI relacionadas y claves derivadas por la aplicación.

Pensemos en un incidente deliberadamente hipotético. Un cliente envía un PUT, el origen responde 204 No Content y un panel declara completada la purga global. La escritura cruzó una caché de aplicación y una pasarela regional. Sin embargo, un nodo de borde que no estaba en esa ruta sigue entregando una colección compuesta con el objeto antiguo. El 204 no identifica ese borde ni la clave derivada que conserva la colección.

No es un defecto de HTTP. Es la frontera entre una regla del protocolo y una afirmación operativa. RFC 9110 considera seguro un método cuando su semántica definida es esencialmente de lectura; GET, HEAD, OPTIONS y TRACE son seguros. Las peticiones que pueden cambiar estado reciben otro tratamiento. Según RFC 9111, una caché debe enviar una petición no segura hasta el origen y no puede generar la respuesta antes de reenviarla y recibir la contestación correspondiente.

La respuesta activa una obligación concreta. Cuando una caché recibe una respuesta sin error a un método no seguro, debe invalidar el URI objetivo. «Sin error» significa aquí un estado 2xx o 3xx. Invalidar puede ser eliminar las respuestas almacenadas coincidentes o marcarlas como inválidas para exigir validación antes de reutilizarlas. La regla evita servirlas sin una comprobación nueva; no certifica que hayan desaparecido todas las copias.

RFC 9111 permite además invalidar otros URI. Location y Content-Location pueden aportar candidatos si comparten origen con el URI objetivo. Es una capacidad útil, pero no un sistema universal de descubrimiento de dependencias. La caché no debe invalidar bajo esta regla un candidato de otro origen, ni está obligada a deducir todas las páginas de producto, listas, búsquedas, fragmentos o claves sustitutas que la aplicación construye a partir del objeto modificado.

La topología impone otro límite. La especificación advierte expresamente que el mecanismo no garantiza una invalidación global: la petición que cambia estado invalida respuestas en las cachés por las que circula. Una caché situada en una ruta de lectura distinta no ha recibido el evento que activa esa obligación local. Multi-CDN, capas de protección omitidas, particiones regionales y rutas separadas de API y páginas convierten esa precisión en un problema de control.

El error consiste en fusionar tres afirmaciones. «El origen aceptó la escritura» habla de la respuesta. «Una caché atravesada invalidó el URI objetivo» habla de una acción local requerida. «Todos los lectores observarán el estado nuevo» habla de topología, derivación de claves y verificación. La primera no prueba la segunda en cada nivel, y ninguna prueba la tercera.

Para cerrar la distancia proponemos un recibo de ruta de invalidación. Es una síntesis editorial de control, no un objeto definido por el IETF. El recibo vincula la petición no segura y su respuesta con las instancias de caché que la transportaron; registra el URI objetivo normalizado y la acción local; distingue la invalidación obligatoria del objetivo del tratamiento opcional de Location o Content-Location; incorpora el mapa de colecciones, búsquedas, fragmentos y claves sustitutas; y conserva sondas sin caché desde cada ruta material de entrega.

Así cambia la pregunta posterior a una escritura. Un 204 deja de interpretarse como un evento global. Se pregunta qué ruta llevó la petición, qué caché actuó, qué identidades quedaron cubiertas y qué lecturas independientes demostraron el nuevo estado. Solo entonces una acción local conforme al protocolo sostiene una afirmación sobre todo el sistema.

Fuentes