Resumen
- La frescura HTTP compara la edad actual con el periodo de frescura; Age no contiene por sí solo esa decisión.
- La prueba operativa debe unir tiempos, directivas, validación, permiso para servir contenido caducado y huella de la representación entregada.
Supongamos que un panel lee Age: 20 en una configuración almacenada y la marca en verde. Parece un valor pequeño. Sin embargo, la respuesta lleva max-age=10 y el caché la entrega como contenido caducado permitido mientras el origen está inaccesible. El encabezado puede ser correcto y la conclusión del panel, falsa.
RFC 9111 separa edad y periodo de frescura. Una respuesta es fresca mientras su edad no haya superado dicho periodo; después es caducada. La comparación real es freshness_lifetime > current_age. Age no identifica la duración aplicable ni reconstruye por sí solo la edad actual.
El periodo tiene una precedencia definida. En un caché compartido manda s-maxage; después puede aplicar max-age, luego la diferencia entre Expires y Date. Si no existe expiración explícita, a veces se permite una estimación heurística. No hay un algoritmo heurístico universal, por lo que dos despliegues conformes pueden calcular plazos diferentes.
Age también es un cálculo. Estima los segundos desde que el origen generó o validó con éxito la respuesta. Puede incorporar el Age recibido, el retraso de respuesta, la diferencia con Date y el tiempo de residencia. Cuando se reutiliza una respuesta almacenada sin validación, el caché debe emitir su edad actual calculada.
Así, un Age de veinte segundos puede ser fresco frente a una vida de sesenta o caducado frente a una vida de diez. Además, una respuesta caducada puede reutilizarse si el caché está desconectado o si existe permiso explícito, salvo que una directiva aplicable como no-cache o must-revalidate lo prohíba. Cumplimiento de protocolo y vigencia empresarial no son la misma cosa.
La solución es un recibo de decisión de frescura. Se trata de una síntesis editorial de evidencias, no de un elemento de protocolo definido por el IETF ni por RFC 9111. Debe registrar identidad y configuración del caché, petición, respuesta almacenada y digest entregado; Date, Age recibido y emitido, tiempos de petición, respuesta y residencia; origen del periodo de frescura, directivas efectivas, validación y resultado, autorización para reutilizar una respuesta caducada y decisión final. Ese conjunto permite reproducir la reutilización sin convertir un único campo en veredicto.
Fuentes
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.1
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.2
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.3
- https://www.rfc-editor.org/rfc/rfc9111.html#section-4.2.4
- https://www.rfc-editor.org/rfc/rfc9111.html#section-5.1
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

