我正在访问我的网站上的链接,每次访问时都会提供一个新图像.
我遇到的问题是,如果我尝试在后台加载图像然后更新页面上的图像,图像不会改变 - 虽然它在我重新加载页面时更新.
var newImage = new Image();
newImage.src = "http://localhost/image.jpg";
function updateImage()
{
if(newImage.complete) {
document.getElementById("theText").src = newImage.src;
newImage = new Image();
number++;
newImage.src = "http://localhost/image/id/image.jpg?time=" + new Date();
}
setTimeout(updateImage, 1000);
}
FireFox看到它们的标题:
HTTP/1.x 200 OK Cache-Control: no-cache, must-revalidate Pragma: no-cache Transfer-Encoding: chunked Content-Type: image/jpeg Expires: Fri, 30 Oct 1998 14:19:41 GMT Server: Microsoft-HTTPAPI/1.0 Date: Thu, 02 Jul 2009 23:06:04 GMT
我需要在页面上强制刷新该图像.有任何想法吗？
尝试在网址末尾添加缓存破解程序:
newImage.src = "http://localhost/image.jpg?" + new Date().getTime();
这将在您创建图像时自动附加当前时间戳,并且它将使浏览器再次查看图像,而不是检索缓存中的图像.
我已经看到了如何做到这一点的答案有很多变化,所以我想我在这里总结一下(加上我自己发明的第四种方法):
newImage.src = "image.jpg?t=" + new Date().getTime();
优点: 100%可靠,快速,易于理解和实施.
缺点:完全禁用缓存,这意味着只要图像在视图之间不发生变化,就会出现不必要的延迟和带宽使用.可能会为浏览器缓存(以及任何中间缓存)填充许多完全相同图像的副本!此外,还需要修改图像URL.
何时使用:在图像不断变化时使用,例如用于实时网络摄像头.如果您使用此方法,请确保使用Cache-control: no-cacheHTTP标头自己提供图像! (通常可以使用.htaccess文件设置).否则,您将逐步使用旧版本的图像填充缓存!
echo '';
(这是PHP服务器端代码,但重要的一点是,文件名附加了一个？m = [文件最后修改时间]查询字符串).
优点: 100%可靠,快速,易于理解和实施,并完美保留缓存优势.
缺点:需要修改图像URL.此外,还需要为服务器做更多工作 - 它必须能够访问文件最后修改时间.此外,还需要服务器端信息,因此不适合纯粹的客户端解决方案来检查刷新的图像.
何时使用:当您想要缓存图像时,可能需要在服务器端不时更新它们而不更改文件名本身.当您可以轻松确保将正确的查询字符串添加到HTML中的每个图像实例时.
Cache-control: max-age=0, must-revalidate,并为URL 添加一个唯一的memcache -busting片段标识符,例如:newImage.src = "image.jpg#" + new Date().getTime();
The idea here is that the cache-control header puts images in the browser cache, but immediately markes them stale, so that and every time they are re-displayed the browser must check with the server to see if they've changed. This ensures that the browser's HTTP cache always returns the latest copy of the image. However, browsers will often re-use an in-memory copy of an image if they have one, and not even check their HTTP cache in that case. To prevent this, a fragment identifier is used: Comparison of in-memory image src's includes the fragment identifier, but it gets stripped of before querying the HTTP cache. (So, e.g., image.jpg#A and image.jpg#B might both be displayed from the image.jpg entry in the browser's HTTP cache, but image.jpg#B永远不会使用image.jpg#A上次显示的内存保留图像数据显示).
优点:正确使用HTTP缓存机制,如果没有更改,则使用缓存的图像.适用于阻塞添加到静态图像URL的查询字符串的服务器(因为服务器永远不会看到片段标识符 - 它们仅供浏览器自己使用).
Cons: Relies on somewhat dubious (or at least poorly documented) behaviour of browsers, in regard to images with fragment identifiers in their URLs (However, I've tested this successfully in FF27, Chrome33, and IE11). Does still send a revalidation request to the server for every image view, which may be overkill if images only change rarely and/or latency is a big issue (since you need to wait for the revalidation response even when the cached image is still good). Requires modifying image URLs.
When to use: Use when images may change frequently, or need to be refreshed intermittently by the client without server-side script involvement, but where you still want the advantage of caching. For example, polling a live webcam that updates an image irregularly every few minutes. Alternatively, use instead of (1) or (2) if your server doesn't allow querystrings on static image URLs.