HTTP 标头中存在 Etag 属性，但不存在缓存控制

发布于 2024-11-16 22:23:47 字数 417 浏览 2 评论 0原文

HTTP/1.1 200 OK
Date: Thu, 23 Jun 2011 07:59:40 GMT
Server: Apache/2.2.16 (Amazon)
Last-Modified: Thu, 23 Jun 2011 07:28:10 GMT
ETag: "68a7f-278-4a65c06e95680"
Accept-Ranges: bytes
Content-Length: 632
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

以上是响应的 http 标头。它没有 Cache-control 属性，但有 Etag 和 Last-Modified 属性。浏览器如何处理这种情况？缓存现在被认为是新鲜的多久？

原文

HTTP/1.1 200 OK
Date: Thu, 23 Jun 2011 07:59:40 GMT
Server: Apache/2.2.16 (Amazon)
Last-Modified: Thu, 23 Jun 2011 07:28:10 GMT
ETag: "68a7f-278-4a65c06e95680"
Accept-Ranges: bytes
Content-Length: 632
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=UTF-8

The above is the http headers for a response. It does not have a Cache-control attribute but has an Etag and Last-Modified attribute. How do browsers handle this situation ? For how long the cache is considered fresh now?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

○闲身 2024-11-23 22:23:47

根据 RFC 2616 第 13.2.4 节：

13.2.4 到期计算
为了决定是否
响应是新鲜的还是陈旧的，我们需要
比较其保鲜期
年龄。年龄计算方式为
第 13.2.3 节中描述；这
部分描述了如何计算
保鲜期，以及
确定响应是否已过期。
在下面的讨论中，值
可以以任何形式表示
适用于算术运算。
我们使用术语“expires_value”来
表示 Expires 的值
标头。我们使用这个术语
“max_age_value”表示
的数量的适当值
“max-age”携带的秒数
缓存控制指令
响应中的标头（请参阅部分
14.9.3)。
max-age 指令需要
优先于过期，所以如果 max-age
存在于响应中，
计算很简单：
 freshness_lifetime = max_age_value
否则，如果 Expires 存在于
响应，计算为：
 freshness_lifetime = 过期值 - 日期值
请注意，这些都不是
计算容易受到时钟的影响
倾斜，因为所有信息
来自源站。
如果没有一个过期，缓存控制：
max-age，或缓存控制：s-
maxage（参见第 14.9.3 节）出现在
响应，并且响应确实
不包括其他限制
缓存，缓存可以计算
使用启发式的新鲜度寿命。
缓存必须附加警告 113
对于任何年龄超过
如果没有此类警告，则 24 小时
已经添加了。
此外，如果响应确实有
上次修改时间，启发式
过期值应该不再存在
比间隔的一部分
从那时起。典型的设置为
这个比例可能是 10%。
计算以确定是否
回复已过期是相当
简单：
 response_is_fresh = (freshness_lifetime > current_age)

According to RFC 2616 Section 13.2.4:

13.2.4 Expiration Calculations
In order to decide whether a
response is fresh or stale, we need to
compare its freshness lifetime to its
age. The age is calculated as
described in section 13.2.3; this
section describes how to calculate
the freshness lifetime, and to
determine if a response has expired.
In the discussion below, the values
can be represented in any form
appropriate for arithmetic operations.
We use the term "expires_value" to
denote the value of the Expires
header. We use the term
"max_age_value" to denote an
appropriate value of the number of
seconds carried by the "max-age"
directive of the Cache-Control
header in a response (see section
14.9.3).
The max-age directive takes
priority over Expires, so if max-age
is present in a response, the
calculation is simply:
  freshness_lifetime = max_age_value
Otherwise, if Expires is present in
the response, the calculation is:
  freshness_lifetime = expires_value - date_value
Note that neither of these
calculations is vulnerable to clock
skew, since all of the information
comes from the origin server.
If none of Expires, Cache-Control:
max-age, or Cache-Control: s-
maxage (see section 14.9.3) appears in
the response, and the response does
not include other restrictions on
caching, the cache MAY compute a
freshness lifetime using a heuristic.
The cache MUST attach Warning 113
to any response whose age is more than
24 hours if such warning has not
already been added.
Also, if the response does have a
Last-Modified time, the heuristic
expiration value SHOULD be no more
than some fraction of the interval
since that time. A typical setting of
this fraction might be 10%.
The calculation to determine if a
response has expired is quite
simple:
  response_is_fresh = (freshness_lifetime > current_age)