检测版本变更

前端保存一个版本
每次请求响应头带一个,这样也可以
 
先面试通过前端页面判断的
version-polling
JoeshuTTUpdated May 30, 2024
remote-file-monitor
jianxiaoBaiUpdated Feb 19, 2024

1.需求分析

通常前端项目经开发迭代需求或者临时修复bug而上线后,我们都希望用户端能迅速检测项目已更新而去刷新页面。检测项目跟新的方法有很多,我这里提供一个适用度较高的简单易行的方法。

2.代码示例及分析

先直接贴源码:
其实逻辑非常简单,就是在记录首次请求时协商缓存中的etag或者last-modified作为最先的时间戳previousTimeTag,然后轮询请求同样的地址获取最新的时间戳currentTimeTag。如果previousTimeTagcurrentTimeTag不一致,执行刷新提示逻辑。流程图如下所示:
notion image
缺陷:如果服务器禁止协商缓存,那就没办法使用该方法了。

3.代码细节分析

1.etag和last-modified

notion image
两者都是响应头中记录关于协商缓存的字段。
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...
目录
文章列表
王小扬博客
产品
Think
Git
软件开发
计算机网络
CI
DB
设计
缓存
Docker
Node
操作系统
Java
大前端
Nestjs
其他
PHP