4.2.2. Calculating Heuristic Freshness
rfc 7234 4.2.2. Calculating Heuristic Freshness
MAY
a cache MAY assign a heuristic expiration time when an explicit time
is not specified
MUST NOT
A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response.
就是如果从stored response能获取到明确的过期时间就禁止(MUST NOT)使用Heuristic Freshness。也就是说stored response中至少具有如下之一:
- s-maxage
- max-age
- Expires+Date
可以使用Heuristics的情况
A cache MUST NOT use heuristics to determine freshness when an
explicit expiration time is present in the stored response. Because
of the requirements in Section 3, this means that, effectively,
heuristics can only be used on responses without explicit freshness
whose status codes are defined as cacheable by default (see Section
6.1 of [RFC7231]), and those responses without explicit freshness
that have been marked as explicitly cacheable (e.g., with a "public"
response directive).
满足如下条件就可以计算Heuristic Freshness
- A:!(MUST NOT),and
- B:cacheable:
- stored responsed code is cacheable,or
- marked as expiciltly cacheable
如何计算？
rfc并没有强制规定具体的算法。
LM-Factor 算法
Heuristic Freshness = (Date header - Last-Modified) x 10%
Date header缺失时：
OkHttp使用接收请求时的毫秒数代替
Last-Modified：
OkHttp直接返回0
SHOULD
When a heuristic is used to calculate freshness lifetime, a cache
SHOULD generate a Warning header field with a 113 warn-code (see
Section 5.5.4) in the response if its current_age is more than 24
hours and such a warning is not already present.
Note
Note: Section 13.9 of [RFC2616] prohibited caches from calculating
heuristic freshness for URIs with query components (i.e., those
containing '?'). In practice, this has not been widely
implemented. Therefore, origin servers are encouraged to send
explicit directives (e.g., Cache-Control: no-cache) if they wish
to preclude caching.
