Flask 静态文件缓存问题

你们好，今天才发现不少学习Flask的小伙伴都有这么一个问题，清理缓存好麻烦啊，今天就教你们怎么解决。

你们在使用Flask静态文件的时候，每次更新，发现CSS或是Js或者其余的文件不会更新。

这是由于浏览器的缓存问题。

广泛你们是这几步解决办法。

• 清理浏览器缓存
• 设置浏览器不缓存
• 也有如下这么写的

@app.context_processor
def override_url_for():
    return dict(url_for=dated_url_for)

def dated_url_for(endpoint, **values):
    if endpoint == 'static':
        filename = values.get('filename', None)
    if filename:
        file_path = os.path.join(app.root_path, endpoint, filename)
        values['q'] = int(os.stat(file_path).st_mtime)
        return url_for(endpoint, **values)

若是是我，我不会这么作，效率很低。

 

 

这是  Flask的 config 的源码，里面能够看到，有设置缓存最大时间

SEND_FILE_MAX_AGE_DEFAULT 能够看到，它是一个 temedelta 的值

咱们去更改配置。

 

 

第2行: 咱们引入了 datetime 的 timedelta 对象

第6行: 咱们配置缓存最大时间

这样就解决了缓存问题，不用去写多余的代码，不用去清理浏览器的缓存。

相关文章：

HTTP----HTTP缓存机制

前言

缓存机制无处不在，有客户端缓存，服务端缓存，代理服务器缓存等。在HTTP中具备缓存功能的是浏览器缓存。 HTTP缓存做为web性能优化的重要手段，对于从事web开发的朋友有重要的意义。本文将围绕如下几个方面来整理HTTP缓存：

• 缓存的规则
• 缓存的方案
• 缓存的优势
• 不一样刷新的请求执行过程

缓存的规则

咱们知道HTTP的缓存属于客户端缓存，后面会提到为何属于客户端缓存。因此咱们认为浏览器存在一个缓存数据库，用于储存一些不常常变化的静态文件（图片、css、js等）。咱们将缓存分为强制缓存和协商缓存。下面我将分别详细的介绍这两种缓存的缓存规则。

强制缓存

当缓存数据库中已有所请求的数据时。客户端直接从缓存数据库中获取数据。当缓存数据库中没有所请求的数据时，客户端的才会从服务端获取数据。

 

协商缓存

又称对比缓存，客户端会先从缓存数据库中获取到一个缓存数据的标识，获得标识后请求服务端验证是否失效（新鲜），若是没有失效服务端会返回304，此时客户端直接从缓存中获取所请求的数据，若是标识失效，服务端会返回更新后的数据。

 

小贴士：

两类缓存机制能够同时存在，强制缓存的优先级高于协商缓存，当执行强制缓存时，如若缓存命中，则直接使用缓存数据库数据，不在进行缓存协商。

缓存的方案

上面的内容让咱们大概了解了缓存机制是怎样运行的，可是，服务器是如何判断缓存是否失效呢？咱们知道浏览器和服务器进行交互的时候会发送一些请求数据和响应数据，咱们称之为HTTP报文。报文中包含首部header和主体部分body。与缓存相关的规则信息就包含在header中。boby中的内容是HTTP请求真正要传输的部分。举个HTTP报文header部分的例子以下：

接下来咱们将对HTTP报文中出现的与缓存规则相关的信息作出详细解释。（咱们依旧分为强制缓存和协商缓存两个方面来介绍）

 

强制缓存

对于强制缓存，服务器响应的header中会用两个字段来代表——Expires和Cache-Control。

Expires

Exprires的值为服务端返回的数据到期时间。当再次请求时的请求时间小于返回的此时间，则直接使用缓存数据。但因为服务端时间和客户端时间可能有偏差，这也将致使缓存命中的偏差，另外一方面，Expires是HTTP1.0的产物，故如今大多数使用Cache-Control替代。

Cache-Control

Cache-Control有不少属性，不一样的属性表明的意义也不一样。 private：客户端能够缓存 public：客户端和代理服务器均可以缓存 max-age=t：缓存内容将在t秒后失效 no-cache：须要使用协商缓存来验证缓存数据 no-store：全部内容都不会缓存。

协商缓存

协商缓存须要进行对比判断是否可使用缓存。浏览器第一次请求数据时，服务器会将缓存标识与数据一块儿响应给客户端，客户端将它们备份至缓存中。再次请求时，客户端会将缓存中的标识发送给服务器，服务器根据此标识判断。若未失效，返回304状态码，浏览器拿到此状态码就能够直接使用缓存数据了。 对于协商缓存来讲，缓存标识咱们须要着重理解一下，下面咱们将着重介绍它的两种缓存方案。

Last-Modified

Last-Modified： 服务器在响应请求时，会告诉浏览器资源的最后修改时间。

if-Modified-Since: 浏览器再次请求服务器的时候，请求头会包含此字段，后面跟着在缓存中得到的最后修改时间。服务端收到此请求头发现有if-Modified-Since，则与被请求资源的最后修改时间进行对比，若是一致则返回304和响应报文头，浏览器只须要从缓存中获取信息便可。 从字面上看，就是说：从某个时间节点算起，是否文件被修改了

1. 若是真的被修改：那么开始传输响应一个总体，服务器返回：200 OK
2. 若是没有被修改：那么只需传输响应header，服务器返回：304 Not Modified

if-Unmodified-Since: 从字面上看, 就是说: 从某个时间点算起, 是否文件没有被修改

1. 若是没有被修改:则开始`继续'传送文件: 服务器返回: 200 OK
2. 若是文件被修改:则不传输,服务器返回: 412 Precondition failed (预处理错误)

这两个的区别是一个是修改了才下载一个是没修改才下载。 Last-Modified 说好却也不是特别好，由于若是在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会由于Last-Modified时间匹配不上而返回了整个实体给客户端（即便客户端缓存里有个如出一辙的资源）。为了解决这个问题，HTTP1.1推出了Etag。

Etag

Etag： 服务器响应请求时，经过此字段告诉浏览器当前资源在服务器生成的惟一标识（生成规则由服务器决定）

If-None-Match： 再次请求服务器时，浏览器的请求报文头部会包含此字段，后面的值为在缓存中获取的标识。服务器接收到次报文后发现If-None-Match则与被请求资源的惟一标识进行对比。

1. 不一样，说明资源被改动过，则响应整个资源内容，返回状态码200。
2. 相同，说明资源无意修改，则响应header，浏览器直接从缓存中获取数据信息。返回状态码304.

可是实际应用中因为Etag的计算是使用算法来得出的，而算法会占用服务端计算的资源，全部服务端的资源都是宝贵的，因此就不多使用Etag了。

缓存的优势

1. 减小了冗余的数据传递，节省宽带流量
2. 减小了服务器的负担，大大提升了网站性能
3. 加快了客户端加载网页的速度 这也正是HTTP缓存属于客户端缓存的缘由。

不一样刷新的请求执行过程

1. 浏览器地址栏中写入URL，回车 浏览器发现缓存中有这个文件了，不用继续请求了，直接去缓存拿。（最快）
2. F5 F5就是告诉浏览器，别偷懒，好歹去服务器看看这个文件是否有过时了。因而浏览器就胆胆襟襟的发送一个请求带上If-Modify-since。
3. Ctrl+F5 告诉浏览器，你先把你缓存中的这个文件给我删了，而后再去服务器请求个完整的资源文件下来。因而客户端就完成了强行更新的操做.