Cache compartida entre clientes: cuándo es correcto

Cuando una respuesta reúne las infracciones de una patente, la regla es conocida: nada de almacenamiento compartido. Ese criterio es correcto y conviene sostenerlo. Aplicado a todo el tráfico por igual, sin embargo, deja afuera una clase de respuestas que sí pueden compartirse y que hoy se recalculan una y otra vez para cada integración.

La decisión no debería depender del ánimo del día. Hay una pregunta que la resuelve casi siempre y, después, una lista corta de condiciones que conviene poder demostrar antes de encender la política.

La pregunta que separa los dos casos

Una caché compartida es la que un intermediario —un CDN, un proxy inverso— usa para responderle a varios solicitantes con la misma copia almacenada. RFC 9111 la distingue de la caché privada, dedicada a un único usuario.

La pregunta que decide es simple: ¿esa respuesta sería idéntica para cualquier cliente autorizado que la pidiera en el mismo instante? Si el cuerpo cambia según quién pregunta —empresa, rol, alcance del token, filtros guardados—, no se comparte. Si depende sólo de parámetros públicos que ya viajan en la URL, es candidata.

“Ahorra latencia” no es un argumento del lado correcto de esa pregunta. La latencia es el motivo; la identidad del contenido es la condición.

Qué suele estar del lado correcto

En una API de infracciones hay superficie compartible real:

• el catálogo de jurisdicciones y sus códigos estables;
• el esquema de la API y su documentación publicada;
• las tablas de referencia que entregamos iguales para todos los clientes;
• los assets versionados con un hash en el nombre.

Nada de eso describe a una persona ni a un vehículo. Cambia por versión, no por solicitante, y vale lo mismo para cualquiera que integre.

Del otro lado quedan los resultados por patente o por documento, los listados de flota, los reportes y cualquier representación que dependa de una sesión. Sobre ese riesgo ya escribimos cuándo una optimización puede filtrar datos.

La clave tiene que determinar el contenido

Una caché parte de método y URI. Vary, definido por RFC 9110, suma los headers que participan en la selección de una variante almacenada. Si una dimensión cambia el cuerpo y no aparece ni en la URL ni en un header que el intermediario ve, esa dimensión no está en la clave y la caché va a mezclar variantes.

Vary alcanza para dimensiones de formato —idioma, compresión—, que viajan en headers estándar. Las que deciden este caso casi nunca lo son: empresa, rol y alcance suelen vivir dentro de un token opaco que el intermediario no interpreta. Por eso el candidato no es sólo “público”: es una representación cuya clave completa entra en la URL. Un catálogo identificado por jurisdicción y versión califica. Un endpoint que devuelve “lo mío” según el token, no.

RFC 9111 agrega un límite propio: una caché compartida no debería reutilizar la respuesta de una solicitud con Authorization para atender pedidos posteriores, salvo que esa respuesta lleve una directiva que lo habilite. Conviene leer esa excepción como lo que es: marcar public una ruta autenticada declara que su contenido puede salir del perímetro de esa credencial. Si eso es cierto, mejor servirlo en una ruta que no pida credenciales; si no lo es, la directiva está mal puesta.

La autorización no se almacena

Un acierto de caché evita llegar al origen y, con eso, evita también el control que el origen hace en cada solicitud. OWASP encabeza su lista de riesgos de APIs con la falla de autorización a nivel de objeto y recomienda verificar el permiso en cada función que usa un identificador del cliente para llegar a un registro. Una respuesta que sirve un intermediario no pasa por ninguna de esas funciones.

De ahí la formulación operativa. La caché compartida es correcta donde no hay nada que autorizar, porque el contenido es el mismo para cualquiera que llegue. En cuanto la respuesta merece un control por identidad, el intermediario deja de ser una optimización y pasa a decidir algo para lo que no fue diseñado.

La Ley 25.326 trata el almacenamiento y la comunicación como formas de tratamiento de datos personales. Una copia en infraestructura de terceros es una copia más, con su propia ubicación, retención y acceso.

Antes de encenderla

Habilitar caché compartida en una ruta pide evidencia, no confianza:

• declará el TTL por ruta, porque sin directivas explícitas una caché puede aplicar su propia heurística de frescura;
• escribí una prueba negativa que confirme que ninguna ruta con resultados quedó adentro de la política;
• probá el camino de invalidación: RFC 9111 prevé invalidación a partir de métodos no seguros sobre el mismo recurso, pero una corrección que nace en otro sistema no llega sola;
• dejá Age visible en la respuesta, para distinguir un dato viejo de uno nuevo cuando alguien reporta una diferencia.

El tercer punto se conecta con cómo se propaga una rectificación: una entrada compartida sobrevive al cambio hasta que vence o se purga.

La política se documenta ruta por ruta y se prueba como cualquier otra regla del contrato. Compartir una copia entre clientes es correcto exactamente cuando esa copia no le pertenece a ninguno.

Metodología

Alcance

Criterio para decidir qué respuestas de una API de infracciones admiten almacenamiento en cachés compartidas y cuáles no; no cubre la configuración de un CDN o proxy particular ni el ajuste fino de sus tiempos de vida.

Unidad de análisis

Una ruta de la API con su clave efectiva de caché, sus directivas declaradas y la respuesta que un intermediario podría reutilizar entre clientes distintos.

Cobertura

Semántica de caché compartida y privada, directivas y selección de variantes según RFC 9110 y RFC 9111, contrastada con criterios de autorización por objeto y con obligaciones generales de tratamiento de datos personales al 29 de agosto de 2026.

Limitaciones

• La nota no constituye asesoramiento legal ni audita la configuración real de un intermediario determinado.
• Los tiempos de vida y la conveniencia de cada política dependen de con qué frecuencia cambia cada recurso y se calibran por ruta.
• Las cachés de aplicación, de cliente y de base de datos siguen reglas propias que no son las de HTTP y se evalúan por separado.

Fuentes

• RFC 9111 — HTTP Caching — RFC Editor (consultada el 2026-08-29)
• RFC 9110 — HTTP Semantics — RFC Editor (consultada el 2026-08-29)
• OWASP API1:2023 Broken Object Level Authorization — OWASP Foundation (consultada el 2026-08-29)
• Ley 25.326 de Protección de los Datos Personales — Argentina.gob.ar (consultada el 2026-08-29)

Preguntas frecuentes

¿Se puede cachear en un CDN el resultado de una consulta por patente?

No como caché compartida. Ese cuerpo depende de quién consulta y describe a un vehículo determinado, así que el valor seguro por defecto es impedir el almacenamiento compartido. Si hace falta velocidad, conviene optimizar dentro del perímetro propio y no en un intermediario.

¿Alcanza con marcar la respuesta como `public` para poder compartirla?

No. `public` habilita almacenamiento compartido incluso donde otras reglas lo impedirían, por ejemplo ante solicitudes con `Authorization`. Es una decisión sobre el alcance del contenido, no una optimización: si la respuesta puede salir del perímetro de esa credencial, conviene servirla en una ruta que no pida credenciales.

¿Qué pasa si el dato cambia mientras la entrada sigue almacenada?

La copia compartida se sigue entregando hasta que vence o se purga. Por eso la política incluye un camino de invalidación probado y `Age` visible en la respuesta: sin eso, una corrección puede tardar en verse aunque el origen ya esté actualizado.

¿Cómo se decide si una ruta admite caché compartida?

Con una sola pregunta: ¿la respuesta sería idéntica para cualquier cliente autorizado en el mismo instante? Si depende de identidad, rol o alcance del token, no. Si depende sólo de parámetros que ya viajan en la URL, es candidata, y todavía hay que verificar que la clave los incluya a todos.

Notas relacionadas