检测版本变更
前端保存一个版本
每次请求响应头带一个,这样也可以
先面试通过前端页面判断的
version-polling
JoeshuTT • Updated May 30, 2024
remote-file-monitor
jianxiaoBai • Updated Feb 19, 2024
1.需求分析
通常前端项目经开发迭代需求或者临时修复bug而上线后,我们都希望用户端能迅速检测项目已更新而去刷新页面。检测项目跟新的方法有很多,我这里提供一个适用度较高的简单易行的方法。
2.代码示例及分析
先直接贴源码:
其实逻辑非常简单,就是在记录首次请求时协商缓存中的
etag
或者last-modified
作为最先的时间戳previousTimeTag
,然后轮询请求同样的地址获取最新的时间戳currentTimeTag
。如果previousTimeTag
和currentTimeTag
不一致,执行刷新提示逻辑。流程图如下所示:缺陷:如果服务器禁止协商缓存,那就没办法使用该方法了。
3.代码细节分析
1.etag和last-modified
两者都是响应头中记录关于协商缓存的字段。
etag是与Web资源关联的记号(token),可以理解是对应Web资源的内容生成的hash码。如果两份Web资源的内容不一致,生成的etag也不一致。属于HTTP1.1的字段。
last-modified用于记录Web资源的最后修改时间。属于HTTP1.0的字段。
引用网上文章来说明为啥etag优先级要高于last-modified
Etag 主要为了解决 Last-Modified 无法解决的一些问题:1、一些文件也许会周期性的更改,但是他的内容并不改变(仅仅改变的修改时间),这个时候我们并不希望客户端认为这个文件被修改了,而重新GET;2、某些文件修改非常频繁,比如在秒以下的时间内进行修改,(比方说1s内修改了N次),If-Modified-Since能检查到的粒度是s级的,这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)3、某些服务器不能精确的得到文件的最后修改时间;
2.HEAD请求方法
HEAD和GET本质是一样的,区别在于HEAD只含有相应中的相应行和响应头,不带响应体。通常用于检测服务器中某个文件是否存在。因为没有响应体,所以相应体积更小,响应时间更短。
3.fetch中的cache设置
default: 协商缓存和强缓存共用
- 如果缓存匹配上并且有效( fresh), 它将直接从缓存中返回资源。
- 如果缓存匹配上但已经过期 ,浏览器将会使用传统( conditional request )的请求方式去访问远程服务器 。如果服务器端显示资源没有改动,它将从缓存中返回资源。否则,如果服务器显示资源变动,那么重新从服务器下载资源更新缓存。
- 如果缓存没有匹配,浏览器将会以普通方式请求,并且更新已经下载的资源缓存。
no-store: 浏览器直接从远程服务器获取资源,不查看缓存,并且不会使用下载的资源更新缓存。
reload: 浏览器直接从远程服务器获取资源,不查看缓存,然后使用下载的资源更新缓存。
no-cache: 浏览器在其HTTP缓存中寻找匹配的请求。
- 如果有匹配,无论是新的还是陈旧的,浏览器都会向远程服务器发出条件请求。如果服务器指示资源没有更改,则将从缓存中返回该资源。否则,将从服务器下载资源并更新缓存。
- 如果没有匹配,浏览器将发出正常请求,并使用下载的资源更新缓存。
更多详细可以查看MDN文档:developer.mozilla.org/zh-CN/docs/…
Loading...