标签: cache-control

HTTP 1.1引入了一类新的标头,Cache-Control响应标头,使Web发布者能够更好地控制其内容,并解决Expires的限制.

由于其局限性,过期是一种痛苦.首先,因为涉及绝对日期,所以必须同步Web服务器上的时钟和客户端的缓存; 如果他们对时间有不同的想法,那么预期的结果将无法实现,而缓存可能会错误地将陈旧的内容视为新鲜的.

Expires的另一个问题是,很容易忘记您已将某些内容设置为在特定时间到期.如果在通过之前未更新Expires时间,则每个请求都将返回到Web服务器,从而增加了负载和延迟.

那么,我们是否需要再使用Expires,或者Cache-Control(具体来说,max-age设置为一些远期的秒数)足以支持我的静态内容？我想避免使用Expires,但我应该同时设置吗？

我有一个相当大的jpg图像文件和几个css文件,这些不会改变每次重新加载,但每次它加载完整的imgae而不是在浏览器中缓存,我尝试更改配置,如config.action_controller. perform_caching = true等但似乎没有任何帮助.有没有办法做到这一点？

我希望有人可以建议使用Varnish发送缓存控制头的正确方法.目前,我的配置是向客户端发送"Cache-Control:no-cache".

提前感谢任何可能提供帮助的人......

我有一个Web应用程序,可以让浏览器长时间缓存AJAX请求.我已经找到了如何在检测到可能的修改时提出完全绕过缓存的请求.但我想让用户触发数据刷新.

在这种情况下,我希望浏览器检查服务器是否停止缓存,但如果不缓存则使用它(即,如果服务器响应304代码).目标是节省加载时间,因为数据量巨大.

服务器在所有响应中包含以下标头:

Cache-Control: private, max-age=604800
Last-Modified: ... # actual last modification date

我设法通过在请求中使用以下HTTP标头完全在Chrome中破解了缓存对象(尚未测试其他浏览器):

Cache-Control: max-age=0
If-Last-Modified: Tue, 01 Jan 1970 01:00:00 +0100

这If-Last-Modified条线是真正具有效果的线.Chrome似乎忽略Cache-Control了请求中的标头.

我还发现Cache-Control: must-revalidate在服务器响应中使用强制浏览器为每个请求验证其缓存与服务器.

但有没有办法重新验证只有一个精确的请求,在客户端决定？

请注意,我并没有特别依赖于使用HTTP标头执行此操作,因此欢迎任何其他我不了解的方法!

我有一个网页,当我访问材料时返回以下标题:

HTTP/1.1 200 OK
Date: Sat, 29 Jun 2013 15:57:25 GMT
Server: Apache
Content-Length: 2247515
Cache-Control: no-cache, no-store, must-revalidate, max-age=-1
Pragma: no-cache, no-store
Expires: -1
Connection: close

使用chrome扩展,我想修改它,response header以便实际缓存材料而不是浪费带宽.

我有以下示例代码:

chrome.webRequest.onHeadersReceived.addListener(function(details) 
    {
        // Delete the required elements
        removeHeader(details.responseHeaders, 'pragma');
        removeHeader(details.responseHeaders, 'expires');

        // Modify cache-control
        updateHeader(details.responseHeaders, 'cache-control', 'max-age=3600;')

        console.log(details.url);
        console.log(details.responseHeaders);

        return{responseHeaders: details.responseHeaders};
    },
    {urls: ["<all_urls>"]}, ['blocking', 'responseHeaders']
);

这正确地将标题修改为这样的东西(基于console.log()输出):

HTTP/1.1 200 OK
Date: Sat, 29 Jun 2013 15:57:25 GMT
Server: Apache
Content-Length: 2247515
Cache-Control: max-age=3600
Connection: close

但基于我试图检查的所有内容,我无法看到任何证据确实发生了这种情况:

1. 在 …

我有一个API服务器的nginx代理.API有时会设置缓存控制标头.如果API没有设置缓存控件,我希望nginx覆盖它.

我怎么做？

我想我想做这样的事情,但它不起作用.

location /api {
  if ($sent_http_cache_control !~* "max-age=90") {
    add_header Cache-Control no-store;
    add_header Cache-Control no-cache;
    add_header Cache-Control private;
  }
  proxy_pass $apiPath;
}

我想确定响应NSURLSessionDataTask来自缓存还是服务器提供

我正在NSURLSessionDataTask从中创建我的

request.cachePolicy = NSURLRequestUseProtocolCachePolicy;

我想告诉ASP.NET Core为Cache-ControlMVC控制器提供的所有响应添加公共和相关标头,包括HTML页面和Web API响应.我不希望策略应用于缓存静态文件; 那些我想要缓存的人.

在特殊情况下,我想禁用缓存,相当于将此属性应用于所有控制器:

[ResponseCache(NoStore = true, Location = ResponseCacheLocation.None)]

我可以创建一个具有此属性的基本控制器,并从中派生所有其他控制器.我想知道是否存在基于配置的方法,以避免需要这样的基本控制器.

我在IIS上运行单页应用程序,并使用i18next库在我的应用程序中进行翻译.问题是,有时当我向translate.json文件添加新关键字并点击刷新时,浏览器仍会使用旧的缓存翻译文件,这会导致用户看到添加的关键字而不是翻译.例如,如果我添加一个关键字,"somekey": "Some text here..."那么somekey将显示而不是指定的文本.

由于我的translation.json文件位于一个名为localesthis 的文件夹中:

locales
    en
      translation.json

我尝试将以下设置添加到web.config:

<location path="locales">
  <system.webServer>
    <staticContent>
      <clientCache cacheControlMode="DisableCache" />
    </staticContent>
  </system.webServer>
</location>

但是,当我使用Chrome开发人员工具查看网络流量时,我注意到translate.json文件仍然来自缓存并且Cache-Control: no-cache标头丢失.为什么这不起作用？什么是禁用文件缓存的正确方法？

编辑:刚刚再次检查该网站,似乎translate.json文件现在有Cache-Control: no-cache标题,每次刷新页面时,实际上都是从服务器检索它.此时我认为该问题可能与我们的发布过程有关,而配置更改未应用.不过不确定.

我已将 AWS CloudFront 设置为从同一域提供静态内容和API 服务器。这意味着我有两种行为，一种为 API 网关/api提供服务，另一种为所有其他路径提供来自 S3 的内容。

问题是我不希望 CF 从 API 服务器缓存任何东西。我很惊讶地发现似乎没有一个“主设置”来完全禁用缓存行为；相反，文档指的是Cache-control: no-cache在原点上使用或在 CF 行为中打开“基于所有标头的缓存”。

但是，这些解决方案中没有一个完全满足我的要求，即不缓存和传递所有标头。如果我添加Cache-control: no-cache到我的起源，CF似乎尊重这一点，但仍然存在CF设置的问题。CF 有一个设置“基于标题的缓存：全部/无/白名单”。文档说要禁用缓存，应该使用“全部”，这是有道理的（尽管与实际设置相比有点模糊：禁用缓存：开/关）。但是，一旦我将此设置设置为“全部”，整个行为就会被禁用，我的 API 请求根本不会到达 API 网关，但默认为用于非 API 请求的 S3 行为。我找不到对此的任何解释，就像整个行为失败或在没有解释的情况下被禁用。

另一个问题是“基于缓存”中不存在的标头不仅会从缓存中排除（无论如何我都不想要），而且还会在转发之前从请求中删除。这对于缓存按预期工作可能是有意义的，但是由于我不想要任何缓存，因此必须确保将我使用过的所有标头列入白名单是非常令人沮丧的。依靠“全部”比必须确保白名单始终是最新的感觉要好得多。

所以：

1) 是否有更好、更清晰的方法来完全禁用 CloudFront 分配的一个路径的缓存？理想情况下，它甚至不应该依赖于设置某些标头的源，它应该完全禁用在配置的路径中缓存请求的任何尝试。

2) 为什么当我在“Cache based on headers”框中选择“All”时，我的整个 API 网关目标都被禁用了？这里发生了什么事？