三种 .htaccess 过期规则之间的区别

发布于 2024-09-24 03:11:09 字数 220 浏览 2 评论 0原文

以下三个 .htaccess 规则之间有什么区别以及何时使用每个规则，是否有任何特殊用例更喜欢其中一个？：

Header set Cache-Control "max-age=290304000"
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
ExpiresDefault "access plus 10 years"

原文

What's the difference between the following three .htaccess rules and when to use each, is there any special use cases that prefers one over the other?:

Header set Cache-Control "max-age=290304000"
Header set Expires "Thu, 15 Apr 2020 20:00:00 GMT"
ExpiresDefault "access plus 10 years"

分享到QQ

分享到微博

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

发布评论

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

迟月 2024-10-01 03:11:09

Header 是一个指令mod_headers 允许修改 HTTP 标头字段。在这种情况下，标头设置有效地设置提到的标头字段Cache-Control 和过期，因此已经存在的标头字段将被覆盖。

第一个指令将标头字段 Cache-Control 设置为值 max-age=290304000，该值将新鲜度生命周期描述为相对于响应时间的 290304000 秒。

与此相反，第二个指令将标头字段 Expires 设置为值 Thu, 15 Apr 2020 20:00:00 GMT，该值描述了新鲜度生命周期的绝对时间价值。

两者Cache-Control的 max-age 值和 Expires 过期时间戳可以相互转换：

4.2.1。计算保鲜期

缓存可以计算新鲜度寿命（表示为
freshness_lifetime）通过使用第一个匹配的响应
以下：
...
如果 max-age 响应指令（第 5.2 节.2.8) 存在，
使用它的值，或者
如果响应标头字段过期（第 5.3 节) 存在，使用
其值减去 Date 响应标头字段的值，或者
...

但是如果两者都存在，Cache-Control 的 max-age 优于 Expires：

如果响应包含带有 max-age 的 Cache-Control 字段
指令（第 5.2.2.8 节），接收者必须忽略过期的
场地。同样，如果响应包含 s-maxage 指令
(第 5.2.2.9 节)，共享缓存接收者必须忽略过期时间
场地。在这两种情况下，Expires 中的值仅用于
适用于尚未实现 Cache-Control 字段的接收者。

无需手动设置这些 HTTP 缓存控制标头字段， mod_expires ExpiresDefault 指令允许轻松设置 HTTP 缓存。新鲜度生命周期可以用绝对值或相对值来描述，可以相对于响应时间（即access/now），也可以相对于修改时间请求的文件（即修改）。它同时使用Cache-Control和Expires。

在这种情况下，第三个指令将默认的新鲜度设置为从响应时间起 10 年。

我会使用 mod_expires 进行 HTTP 缓存控制，而不是使用 Header 手动执行。它更加方便，允许相对和绝对新鲜时间，并使用Cache-Control和Expires。

Header is a directive of mod_headers that allows to modify HTTP header fields. In this case Header set effectively sets the mentioned header fields Cache-Control and Expires, so an already existing header field will be overwritten.

The first directive sets the header field Cache-Control with the value max-age=290304000, that describes the freshness lifetime to be 290304000 seconds relative to the response time.

In contrast to that, the second directive sets the header field Expires with the value Thu, 15 Apr 2020 20:00:00 GMT that describes the freshness lifetime with an absolute time value.

Both Cache-Control’s max-age value and Expires expiration time stamp can be transformed to the other:

4.2.1. Calculating Freshness Lifetime

A cache can calculate the freshness lifetime (denoted as
freshness_lifetime) of a response by using the first match of the
following:
...
If the max-age response directive (Section 5.2.2.8) is present,
use its value, or
If the Expires response header field (Section 5.3) is present, use
its value minus the value of the Date response header field, or
...

But if both are present, Cache-Control’s max-age is preferred over Expires:

If a response includes a Cache-Control field with the max-age
directive (Section 5.2.2.8), a recipient MUST ignore the Expires
field. Likewise, if a response includes the s-maxage directive
(Section 5.2.2.9), a shared cache recipient MUST ignore the Expires
field. In both these cases, the value in Expires is only intended
for recipients that have not yet implemented the Cache-Control field.

Instead of setting these HTTP caching control header fields manually, mod_expires ExpiresDefault directive allows an easy setup for HTTP caching. The freshness lifetime can either be described with an absolute value or with a relative value, either relative to the response time (i.e. access/now) or relative to the modification time of the requested file (i.e. modification). It uses both Cache-Control and Expires.

In this case the third directive sets the default freshness lifetime to be 10 years from the time of response on.

I would use mod_expires for HTTP cache control instead of doing it manually with Header. It is far more convenient, allows both relative and absolute freshness times and uses both Cache-Control and Expires.

回复收藏 0 原文