2010-09-29 103 views
0

如果我设置为我的网站上高速缓存控制:缓存控制问题

Header unset Pragma 
FileETag None 
Header unset ETag 

# 1 YEAR 
<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|swf|mp3|mp4)$"> 
Header set Cache-Control "public" 
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT" 
Header unset Last-Modified 
</FilesMatch> 

# 2 HOURS 
<FilesMatch "\.(html|htm|xml|txt|xsl)$"> 
Header set Cache-Control "max-age=7200, must-revalidate" 
</FilesMatch> 

# CACHED FOREVER 
# MOD_REWRITE TO RENAME EVERY CHANGE 
<FilesMatch "\.(js|css)$"> 
Header set Cache-Control "public" 
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT" 
Header unset Last-Modified 
</FilesMatch> 

...那么如果我更新任何CSS或图片或其他文件,将用户的浏览器仍然使用缓存版本,直到它会过期(一年后)?

由于

回答

1

你的CSS,JS和图像文件将永远不会被缓存,为你设置一个日期过去。

我认为这是一个错误,并且您打算将其设置为未来一年,这是支持max-age过期的一个原因。

如果是这样的话,那么你的图片将被缓存高达一年。可以随时从缓存中删除某些内容,例如清理不常用的条目以减少缓存占用的磁盘大小。

有两种可能的方法来处理降低陈旧风险的可能性。一种是设置更低的到期时间,并使用电子标签和修改日期,以便在到期时间过去之后,如果没有变化,您可以发送304,所以服务器只需要发送几个字节而不是整个实体。

另一个是保持到期一年,但要更改改变时使用的URI。例如,这可以是有用的。一个大型文件,几乎在您网站的每个页面上使用。它要求你改变所有对该资源的引用,因为它确实改变了(因为你基本上正在改变使用新的资源),这可以很费劲,因此只在少数热点情况下被建议作为优化。如果某个文件忽略查询属性(例如,它只是直接从文件中提供),浏览器将不会知道该属性,因此您可以使用类似/scripts/bigScript.js?version=1.2.3的内容,然后在更改bigScript.js时更改为/scripts/bigScript.js?version=1.2.4。这对bigScript.js没有任何影响,但会导致浏览器获得一个新文件,因为它知道它是一个完全不同的资源。

+0

啊哈,所以如果我设置过期到一年或'远期未来',并incase我不得不改变一些缓存的文件,我只会添加像'style.css?ver = 031010'的属性,它会抓住这个新文件?此操作是否跨浏览兼容? – 3zzy 2010-10-03 04:35:48

+1

它完全跨浏览器兼容。请记住,对于所有的浏览器都知道,服务器使用该查询字符串 - 因此它不能假定style.css?ver = 020123与style.css?ver = 031010相同,必须重新获取文件。服务器正在使用相同的文件(只有更新版本的课程)并忽略查询字符串,但它可能会做其他事情。只有重击“库”文件才值得。 – 2010-10-03 12:02:04

+0

太棒了,就是我想知道的。谢谢!另外,我的静态文件(CSS,图像)与HTML所在的域不在同一个域中,因此htaccess的位置在哪里? – 3zzy 2010-10-04 05:12:42

1

是的,在未来的一个response with an expiration date将被视为新鲜直到有效期限:

过期实体头字段给出的日期/时间之后,响应被视为失效。 [...]

未来某个时间的日期值的Expires标头字段在默认情况下默认为不可缓存的响应中表示该响应是可缓存的,除非由Cache-控制标题字段(section 14.9)。

注意,到期日一年以上,将来可能被解释为永不过期

标记为“永不过期”,响应的原始服务器发送一个到期日期从答复发送之日起大约一年。 HTTP/1.1服务器不应在将来发送超过一年的过期日期。

因此,如果缓存中存储的响应,可能将需要从缓存响应,即使没有重新确认发送之前缓存的响应。

现在,如果你更改资源是already stored in caches and still fresh, there is no way to invalidate them

[...]虽然他们可能会继续以“新鲜,”他们没有准确反映原始服务器将返回上一个新的请求资源。

HTTP协议无法保证所有此类缓存条目都被标记为无效。例如,导致原始服务器发生更改的请求可​​能没有经过存储缓存条目的代理。

这是为什么这样从来没有到期的资源用在与每个更新改变网址(例如style-v123.css)唯一的版本号的原因。这也是我在这种情况下推荐的。

顺便说一句,在这种情况下声明与Cache-Control as public的回应没有做任何事情。这仅在需要授权的响应应该可缓存时才会使用:

public - 指示响应可以被任何缓存缓存,即使缓存通常不可缓存或仅缓存在非共享内缓存。 (另请参阅授权,section 14.8,了解更多详情。)

有关HTTP缓存的更多信息: