301重定向后如何防止Chrome从磁盘缓存中加载index.html

时间:2018-12-30 09:32:21

标签: google-chrome http nginx caching

每当我们发布网站的新版本,搜索几天并添加/删除了可能导致此问题或据说已解决的所有标头,元标记,nginx配置等时,我们就会遇到chrome缓存问题它,但是什么都没有改变。 index.html仍在缓存中,我们必须按F5键才能在随机计算机上查看新更改,

该网站使用angularjs框架作为SPA实施,并使用traefik规则使用位于traefik代理后面的ngnix托管,我们通过301响应强制将HTTP请求重定向到HTTPS。

今天我发现了失败的情况!如果用户在地址栏中输入https协议(例如https://example.com),则说明一切正常,但如果用户返回并尝试访问http://example.com,则chrome会通过301重定向将用户重定向到https缓存,然后加载不是我们想要的index.html的缓存版本,可以缓存301重定向,但是我们希望chrome从服务器获取index.html而不是从磁盘缓存中加载它。

注意:只要用户使用HTTPS,索引就会从服务器加载或获得304响应,我们希望这种情况在用户仅输入域本身而不是使用https时发生。

这是添加到index.html的元标记:

<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="pragma" content="no-cache" />

这是我们的nginx配置的一部分:

...
http {
    ...
    proxy_cache_path /var/nginx/cache levels=1:2 keys_zone=prerender_cache:100m max_size=10g inactive=1d;
    proxy_cache_key "$request_method$host$request_uri$is_args$args";
    ...
    server {
        access_log /dev/stdout combined1;
        listen      80 default_server;
        server_name example.com;
        root /app;
        index  index.html;
        ...
        location ~ ^/(assets|static|styles) {
            expires     31d;
            add_header  Cache-Control public;
        }
        location @asset_pass {
            root app/;
            try_files $uri =404;
        }
        location / {
            expires -1;
            add_header Pragma "no-cache";
            add_header Cache-Control "no-store, no-cache, must-revalicate, post-check=0 pre-check=0";
            try_files $uri @prerender;
            autoindex on;
        }
        location ~ \.html$ {
            expires -1;
            add_header Pragma "no-cache";
            add_header Cache-Control "no-store, no-cache, must-revalicate, post-check=0 pre-check=0";
        }
    }
}

现在的问题是:有什么办法可以解决这个问题,或者这是谷歌浏览器的默认行为?

谢谢大家花时间阅读此问题,如果回答时间过长,则表示抱歉。

1 个答案:

答案 0 :(得分:0)

您可以尝试touch您的index.html文件,然后响应标头last-modified将更改为最新日期时间,因此浏览器将认为此资源已“过时”,最新301规则为已应用;