Chrome keeps loading an image from cache, even when I have the dev tools open, and have disabled cache.
Why does Chrome do this?
How to make it stop?
The image you're loading is a base64 encoded inline image. That means it's no loaded via a separate HTTP request, but instead is embedded inside your HTML, CSS or JavaScript code.
The URL could look like this for example: data:image/png;base64,iVBORw0KG....
Chrome is treating it as a request to a data: url, but since no server roundtrip is required to look it up Chrome shows it as "(from cache)". (This isn't quite accurate but does make some sense.)
Related
If I've loaded an image into an html page, when I load it a second time further down in that page will it be instantly available?
Depends on the headers sent with the image, but I believe most browsers will cache images automatically. That should work fine as long as the URL is the same. Check the network request to make sure the image is only being requested once from the server.
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
I have an application that uses Google Drive for document storage and preview functionality, but recently the iFrames that the documents are loading into are not displaying anything. Upon inspection of the console, Chrome declares that it blocked the fram from running insecure content, and that is why the file preview did not load.
The initial call to preview this file is to a url that looks like this:
https://docs.google.com/document/d//preview
There is a redirect along the way that takes the following form but because it uses http instead of https, Chrome blocks the content from loading.
http://www.google.com/url?sa=p&q=https://www.google.com/accounts/ServiceLogin?service%3Dwise%26passive%3Dtrue%26go%3Dtrue%26continue%3Dhttps://docs.google.com/document/d//preview?pref%253D2%2526pli%253D1
Is there any way around this issue? It is blocking a core functionality of my application currently, so any advice would be appreciated. I can provide a screenshot of the full stack of network loads in necessary, but this is the only URL that is not http compliant.
Thanks in advance for your help.
Hacked that. Add a "?pli=1" without quotes at the end of the URL to avoid redirect (after "/preview" or "/edit") and land directly to the document.
How do I force caching of pages, scripts, images(resources) including the results of dynamicly generated content (php,asp,etc etc), I do not have control of the website in question and I understand that if I cache a dynamic page it becomes static,, thats fine for me,,
However... I do not want to cache everything.. the pages loads default.asp,,,as well as a tone of .js scripts,,, in turn which make calls to a API returning some XML,,
I want to cache the default.asp and all .js but not the xml files.
im using chrome and chrome is aggressively caches what it can but all the stuff from this site has a max-age=0 header.
so from chrome how can I override headers for individual resources?
I have an app that displays the same image in multiple locations and may change the src of an image.
When I point to a PNG image that I've already used before, the browser does not bother making a new request, it simply uses the PNG image that's already in the cache. However, when I point to an SVG image image that I've used before, the browser (Chrome 22) makes a new request. The server returns 304 (Not Modified), so no new image needs to be downloaded, but this still takes some extra processing.
This can be easily tested in this jsFiddle: http://jsfiddle.net/jtmuw/1/
$('button').click( function() {
$('#a').attr('src', "myImage.svg");
$('#b').attr('src', "myImage.png");
});
If you open the fiddle with Chrome (or at least Chrome v.22.0.1229.94) and you open up your network tab you will see the two images have been requested. If you then hit "reload images" several times, your network tab will show multiple requests for the SVG image but no further requests for the PNG image.
As far as I can tell, the same headers are being returned by the server, so I can't see any reason for the difference.
I am not seeing this on FF or Safari, so this may be a Chrome issue. However, I still feel like maybe there is some underlying differences in the headers that I'm missing, and it's not just that Chrome is treating SVG images weirdly.
You can perhaps force Chrome to cache the file. w3schools has a pretty good overview of this as follows: http://www.w3schools.com/html/html5_app_cache.asp
Essentially you'll want to create a manifest file (call it... "myCache.appcache" or whatever else)
CACHE MANIFEST
/path/to/svg/file.svg
and then point to this in your html file as so:
<html manifest="myCache.appcache">
This will tell Chrome that, even when you don't have internet access, this file should be cached and accessible anyway.
Include the SVG image at the top of the document.
<html>
<head>
...
</head>
<body>
<img style="display:none" src="cached.svg">
....
</body>
<html>