Resumen

  • RFC 9111 permite combinar fallos en una sola petición reenviada únicamente si la respuesta puede reutilizarse para las peticiones implicadas.
  • Cada petición en espera mantiene su propia decisión sobre objetivo, método, campos Vary, autorización y controles de caché.

Imaginemos una pasarela de borde en un caso expresamente hipotético. Dos peticiones GET para el mismo URI llegan casi a la vez. Una es anónima; la otra contiene Authorization y espera una representación propia de la cuenta. La pasarela toma la primera como petición de referencia, hace una sola consulta al origen y entrega el 200 OK a ambas. Reduce carga, pero oculta dentro de la optimización la decisión que correspondía a la segunda petición.

RFC 9111 admite esta combinación por una razón práctica. Cuando varias entradas fallan a la vez, la caché puede convertirlas en una sola petición reenviada para aliviar el origen y la red. Esta posibilidad está condicionada a que la respuesta pueda reutilizarse para las peticiones de que se trate. Si no sirve para alguna, esa petición tiene que reenviarse, aunque ello añada latencia.

La condición importa porque la semejanza del URI no decide la reutilización. El URI objetivo debe coincidir; el método asociado a la respuesta almacenada debe permitir su uso; los campos designados por Vary deben corresponder; las condiciones no-cache deben cumplirse; y la respuesta debe estar fresca, poder servirse obsoleta o haber sido validada. La combinación cambia el número de consultas al origen, no estas condiciones por petición.

Vary aporta una parte de la decisión. RFC 9110 dice que enumera campos de la petición que pudieron influir en la selección de la representación y amplía la clave de caché usada en coincidencias posteriores. RFC 9111 define cómo comparar esos campos, incluida su normalización y ausencia. Un Vary que contiene * nunca coincide. En lugar de fundir las peticiones, Vary ofrece evidencia para diferenciarlas.

Authorization concreta el límite. RFC 9111 impide que una caché compartida reutilice una respuesta a una petición con Authorization en peticiones posteriores, salvo que una directiva Cache-Control lo habilite y se respeten sus requisitos. No significa que todo grupo sea autenticado. Significa que la difusión no puede saltarse los controles que regirían una reutilización normal.

Por eso es peligroso medir solo «peticiones al origen ahorradas». La recuperación exitosa de la petición de referencia prueba que una transacción devolvió una respuesta. No demuestra que cada petición asociada comparta campos de selección, restricciones de autorización, estado de frescura o permiso de uso. Si difieren, reenviar por separado es corrección, no desperdicio.

Un recibo de liberación del grupo puede conservar capacidad y evidencia. Es una síntesis editorial de control, no un objeto definido por el IETF. Vincula la petición de referencia con cada petición en espera, registra la respuesta y el objeto almacenado, normaliza método y objetivo, compara campos Vary, evalúa Authorization y Cache-Control y deja para cada una la decisión de entrega o de reenvío independiente.

Así se separa la optimización del derecho de uso. Una consulta puede compartirse; cada entrega sigue siendo una decisión individual. El operador puede contabilizar trabajo evitado sin llamar acierto a una difusión indebida.

Fuentes