Ctrl+F5是否仍然需要用于强制加载网站的最新JavaScript?

huangapple go评论70阅读模式
英文:

Is Ctrl+F5 still necessary to force the latest JavaScript to load for a website?

问题

我们的首席网页开发人员说:

"JavaScript 代码现在已经版本化在我们的新代码中,并且应在发布新版本时自动刷新。但我们仍然发现它并不总是有效。请随时向 Google 和 Microsoft 报告此问题。"

所以我想问一下,2023 年这是否仍然存在?他可能不知道的一些选项是什么?

我没有资格回答这个问题,所以我之所以问比我聪明的人。

我在 Stackoverflow 上搜索了一些答案并将它们发送给了他。他的回复在上面的引号中。

英文:

Our lead web developer is saying:

"The JavaScript code is now versioned in our new code and should automatically refresh when a new version is out. Yet we are still finding that it doesn’t always work. Feel free to raise this with Google and Microsoft".

So I'm asking. Is this still "a thing" in 2023? What are some options that he might not be aware of?

I am not qualified to answer this, so that is why I am asking smarter minds than my own.

I searched through the answers here on Stackoverflow and sent them to him. His reply is in the quote above.

答案1

得分: 1

任何类型的页面额外内容的基于URL的版本控制方式,都可以像这样实现:

  1. 构建系统(无论是什么)使用某种技术将特定的数字与完整构建关联起来,并使该数字可用于构建主要页面。过去我曾使用过时间戳(对于开发很方便)以及源代码库头部修订号或发布编号等。

  2. 主要页面的组装(包括脚本等的导入)被设置为使用<script>标签,其中的URL通过URL中的虚拟参数请求相同的版本号:

<script src="/my/app/goodies.js?_=81992"></script>

虚拟参数使得该URL在浏览器看来就像是一个全新的URL,缓存无法识别。这意味着“缓存中是否有这个?”的测试将失败,浏览器将获取最新部署的文件。

请注意,特殊的构建或时间戳ID值除了击败浏览器缓存之外什么都不做。

对于CSS、图像等也是同样的道理。

一个更弱的做法是在客户端计算一个随机数值作为虚拟参数。如果你可以生成一个相当大的随机数并将其用作虚拟参数,那通常会起作用,但我个人不希望出现那种类型的错误。

还有一点:如果你的系统不涉及可能会超时的会话(比如一个非安全内容的网站),那种类型的缓存避免就行不通,因为浏览器会继续假设主页已被缓存,并且它不会有更新的脚本URL。在这种情况下,你可以使用每个资源的“Etag”,或设置你的“Expires”头,或使用“Last-Modified”和“If-Modified-Since”进行基于时间的缓存过期检查。

英文:

The way URL-based versioning of any sort of extra content for pages, content fetched by simple GET requests issued implicitly by the browser, is something like this:

  1. The build system (whatever that may be) uses some technique for associating a particular number with a complete build, and makes that number available for the construction of the main pages. In the past I've used timestamp (handy for development) and source repository head revision number or release id or whatever.

  2. The assembly of the main pages (where scripts etc. are imported) are made to use &lt;script&gt; tags with URLs requesting that same version id via a dummy parameter in the URL:

&lt;script src=&quot;/my/app/goodies.js?_=81992&quot;&gt;&lt;/script&gt;

The dummy parameter makes that URL look like a whole new URL to the browser, one that the cache does not recognize. That will mean that the "is this in the cache?" test will fail, and the browser will fetch the latest deployed file.

Note that the special build or timestamp id value does not do anything other than defeat browser caching.

Same goes for CSS, images, etc.

A weaker way of doing this is computing a nonce value on the client. If you can make a fairly large random number and use it as the dummy parameter, that will usually work, but personally I don't want those kinds of bugs.

One more thing: if you have a system that does not involve sessions that can time out (like a non-secured content website), that kind of cache avoidance won't work, because the browser will continue assuming the main page is cached, and it won't have updated script URLs. In that case, you can either go with an "Etag" for each resource, or set your "Expires" headers, or use "Last-Modified" and "If-Modified-"Since" to do time-based checks for cache expiration.

huangapple
  • 本文由 发表于 2023年7月3日 07:07:07
  • 转载请务必保留本文链接:https://go.coder-hub.com/76601101.html
匿名

发表评论

匿名网友

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen:

确定