当 srcache 返回缓存响应时更新 Cache-Control max-age

当 srcache 返回缓存响应时更新 Cache-Control max-age

我已经将 Nginx 配置为使用 srcache(以及 redis 和 redis2 模块)。服务器端缓存效果很好。我的应用程序使用适当的ExpiresCache-Control标头进行响应,srcache 将相应地存储和从 Redis 缓存中获取数据。

我希望我的响应能够被服务器之外的浏览器和代理缓存。ExpiresCache-Control标头已发送。但是,Cache-Control max-age不会自动更新。我猜想这是因为此标头实际上存储在缓存中。请注意这些响应上的日期,并且标头max-ageCache-Control的 仍为2592000...其初始值。

HTTP/1.1 200 OK
Server: nginx/1.2.9
Date: Tue, 01 Jul 2014 15:18:19 GMT
Content-Type: application/javascript
Content-Length: 2710
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 31 Jul 2014 15:13:00 GMT
Cache-Control: public, max-age=2592000, must-revalidate, proxy-revalidate
X-SRCache-Key: fde32bfe93fcf90c398e9ed585991146
X-SRCache-Fetch-Status: HIT
X-SRCache-Store-Status: BYPASS


HTTP/1.1 200 OK
Server: nginx/1.2.9
Date: Tue, 01 Jul 2014 15:22:13 GMT
Content-Type: application/javascript
Content-Length: 2710
Connection: keep-alive
Vary: Accept-Encoding
Expires: Thu, 31 Jul 2014 15:13:00 GMT
Cache-Control: public, max-age=2592000, must-revalidate, proxy-revalidate
X-SRCache-Key: fde32bfe93fcf90c398e9ed585991146
X-SRCache-Fetch-Status: HIT
X-SRCache-Store-Status: BYPASS

有什么办法可以纠正这个问题吗? 以下是我的 Nginx 配置的相关部分:

location / {
    # Caching keys
    set_md5 $srcache_key $request_uri; 

    srcache_ignore_content_encoding on;
    srcache_methods GET;
    srcache_fetch GET /redisFetch $srcache_key;
    srcache_store PUT /redisStore key=$srcache_key&exptime=$srcache_expire;

    add_header X-SRCache-Key $srcache_key;
    add_header X-SRCache-Fetch-Status $srcache_fetch_status;
    add_header X-SRCache-Store-Status $srcache_store_status;
    add_header X-SRCache-Expire $srcache_expire;

    include /apps/*/nginx/api.conf;
}

location = /redisFetch {
    internal;

    set $redis_key $args;
    redis_pass redis_cache;
}

location = /redisStore {
    internal;

    redis2_query set $arg_key $echo_request_body;
    redis2_query expire $arg_key $arg_exptime;
    redis2_pass redis_cache;
}

答案1

max-age 值指定了对象应被视为新鲜状态的秒数。也就是说,它将是可缓存的,包括浏览器在内,因此如果您的目标是启用缓存,那么您可能实际上不需要对 Cache-Control: max-age 做任何事情。更令人担心的是您的 Pragma: no-cache 标头。同样,在您的 Cache-Control 标头中,您指定了 must-revalidate。这意味着客户端通常仍需要发出请求,但请求将包含 If-Modified-Since 标头,然后服务器只需发送 304 响应,而不必重新发送内容。您应该考虑这是否是您真正想要的行为。

以下是对各种缓存标头的合理解释[http://www.mobify.com/blog/beginners-guide-to-http-cache-headers/]或者你可以去 RFC 寻找更正式的权威说法 [http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

通常不需要“更新”最大年龄值,除非您提前知道服务器端何时生成下一版本的内容,并且使用 CC:max-age 的固定值比每次进行日期计算更能减少生成标题的麻烦。

对于能够理解 Cache-Control 的客户端(大多数客户端,甚至是声称是 HTTP/1.0 的客户端),Cache-Control 标头的优先级高于 Expires 标头。

如果您的 Expires 标头已正确生成,并且 max-age 值不是您想要的,那么最简单的解决方案可能是抑制CC: max age它而不是纠正它。(http://wiki.nginx.org/HttpHeadersMoreModule

相关内容