I am publishing a Visio 2013 drawing to a site (using File->Export->Change File Type->Web Page (*.htm). The website is checked into CM and then labeled. My web server has a (ClearCase) view based on this label that automatically refreshes itself.
What I'm finding is that my browsers are always showing the cached (old) version of the pages. I've been able to change my IE browser settings so that it always refreshes the cache (Internet Options->General Tab->Settings->Check for newer versions of stored pages = Every time I visit the webpage. When I do this, I see the changes.
But, this isn't a real solution. I don't want to have to tell my viewers to change their browser settings so it automatically refreshes. Is there something I need to do to the page contents to tell all browsers to refresh?
You can handle caching of browsers through the http response your server provides.
The Cache-Control field of the http response no-cache can prevent clients from caching the drawing if it is something you expect would be refreshed often: Mozilla Docs
Alternatively you can set the Expires field of the http response to expire after a day if the image would be updated on a periodic basis: Mozilla Docs
The following question has a good comparison of the two: what’s the difference between Expires and Cache-Control headers?
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.
My web page sometimes (rarely) shows "there are some insecure resources" warning icon (yellow lock) like in the screenshot below. However that occurs rarely and now I caught another one I don't want to miss it again so I can't risk losing the page.
The page is at the URL: https://eksisozluk.com/sedat-kapanoglu-ve-40-kisiye-hapis-talep-edilmesi--3960310 . You will probably not see the warning (unless it's Firefox) because I didn't in my consecutive tries on Chrome and I was logged in when I got the error. So let's assume you and I will never see that warning icon on Chrome again.
Devtools was not open when I was using the site, so "Network" tab is empty. That part won't work.
"Resources" shows all JS and CSS entries as https there is no single resource from http there.
The page has jQuery loaded so I tried queries $('*[href^="http:"]') and $('*[src^="http:"]') to no avail. The page contains some external http links (not resources, plain a href's) but that wouldn't trigger the alarm.
I'm using Kaspersky Anti-Virus and it uses a proxy to scan incoming/outgoing traffic. That could be causing some trouble although I haven't had any issues so far with other web sites.
I tried "view page source" and searching it for http resources but only tag with http resource link was:
<meta name="twitter:image" content="http://eksisozluk.com/content/img/ilogo120.png" />
which actually exists in the page when the icon is green too. So that cannot be the reason.
Isn't there a way to directly view the "insecure content" whatever that is in Chrome?
When I view the page in Firefox it says "partially encrypted" but it doesn't show what's not encrypted either. All the items in "Media" tab start with "https://".
Actually now I'm able to reproduce the issue continuously on Firefox. I looked at the network tab and "nothing" shows as http:// yet Firefox tells me "partially encrypted". I'm not sure if Firefox is saying that for the same reason Google does (because Firefox is consistent and insistent about it), but I'm providing both scenarios in case they belong to the same root cause.
I finally wrote this code in Chrome console to find the culprit:
$("*").each(function (index, elem) {
var attrs = elem.attributes;
for(var n = 0; n < attrs.length; n++) {
var attr = attrs[n];
if(attr.nodeValue.indexOf("http://") >= 0) {
console.log("FOUND: <" + elem.nodeName + " " + attr.nodeName + "='" + attr.nodeValue + "'>");
console.log($(elem));
}
}
});
The output shows no interesting stuff. Only <META content> for twitter reference, <A href>s and two <TD title="http://...">s that Mvc-Mini-Profiler inserted. None of them justify the warning of course. Here is the full output: http://pastebin.com/kgV8XHgN
So this looks really interesting. There is NOT a single element in DOM that contains an "HTTP" link yet Chrome warns about "insecure" content. I'm very troubled by it.
There are NO iframes on the page. ($("iframe") returns [])
EDIT: DAMN I lost the page :( (navigated to a link and back button turned to SSL icon to green). I knew it wouldn't last long. But I still appreciate any help since it wasn't the first time I saw that issue.
Just had this problem – if you check the Javascript Console in Chrome it will now tell you where the problem lies.
I had the same issue yesterday, and found http://www.whynopadlock.com/
It shows which elements are not secure, and it also verifies certificate chains.
Btw, if your site can be loaded both http and https, then omit http: from external urls.
Not:
src="http://external.dom/external.js" or "https://external.dom/external.js"
Just:
src="//external.dom/external.js"
Then the browser will use http or https depending on what the page is loaded as
I just spent an hour with a similar problem, I got the green ssl lock in Chrome and IE but not in Firefox (only after page reload).
First of all: To debug SSL issues, the httpfox plugin seems to be better than firebug's network tab. Firebug showed all sources as https, but looking at httpfox, I quickly found the culprit: Google Analytics was loading the ___utm.gif tracking pixel via http. This tracking pixel came from the previous page, where I was tracking a Google Analytics event which was attached to a button click.
This seems to be a bug in Firefox: When tracking a GA event from a http page to a https page (e.g. Proceed button click), FF will load the tracking pixel via http on the https page, causing the error.
I removed the event from the button and FF stopped complaining about the partially encrypted connection.
It sounds most likely that an AJAX resource was used with an http:// URL... you would most likely need the network panel or console to check that.
Firefox's built-in developer tools have them.
A quick solution is to add target="_blank" in each <a> element. It will open the link in new window. Working on all browsers.
We have a mobile web app saved to the home screen. The application is coded using a single page HTML file with jquery mobile.
In iOS5 and below the index.html file is not cached by the device so every time the application is launched the device requests for the HTML page. This is really important because we have another application that handles authentication sitting in front of our server and therefore we rely on the 302 http code which causes a redirect to authenticate. If this is successful another redirect occurs back to our index.html page.
In iOS6 though it appears the index.html file is cached even though we set a no cache control header! This is a problem because we don't get to authenticate and therefore when the user starts using the application all requests fail (they are unauthenicated).
I can't seem to find any detail of whether this was a feature implemented in iOS6. Anyone shed any light on this? I know they went a little crazy with caching (caching post responses)...
NOTE: understand the solution of the authentication is not ideal however we can't change that at the moment. Just looking for references on what apple did to cause this bug!
Update:
Just discovered something interesting after using Charles Web Debugging Proxy that the server is responding with Cache-Control:private which means that proxies won't cache however browsers will cache. This raises the question as to whether iOS 6 home screen mobile web apps now actually treat this cache-control correctly?!? Need to investigate further what hardware in our infrastructure is adding this cache-control.
I am having the same issue with an HTML5/JQM/Jersey based application. I set the cache-control header to no-cache, which now seems to work on most of the devices but still fails intermittently on some.
I was struggling with the same issue in my application, and founded that you have to set the headers of the request with Cache-control: no-cache, in order to avoid iOS6 cache the response.
Please take a look to the following link:
Is Safari on iOS 6 caching $.ajax results?
If you use:
Cache-Control:no-cache, no-store
there shouldn't be any way for iOS6 to cache the AJAX calls. I suspect iOS6 actually started obeying the rules and implemented "Cache-control:private" as it was meant to work initially, while almost any other browser just treats it as 'no-cache' directive.
I had the same problem with it, while using PHP's SAJAX framework (which was set to 'private').
I am developing a web app for offline use, thus I need to use the application cache functionality.
Everything works great on Chrome (15.0.874.106) but is doesn't work on Firefox (7.0.1) and Opera (11.52).
This is my cache manifest file cache.manifest.php (I have reduced it to the bare minimum):
<?php
header("Cache-Control: max-age=0, no-cache, no-store, must-revalidate");
header("Pragma: no-cache");
header("Expires: Wed, 11 Jan 1984 05:00:00 GMT");
header('Content-type: text/cache-manifest');
?>CACHE MANIFEST
CACHE:
/app/common/css/reset.css
/favicon.ico
And this is the first 4 lines of the "main" HTML document:
<!DOCTYPE html>
<html manifest="/app/mobile/cache.manifest.php">
<head>
<title>MyApp Mobile</title>
When I try and load the cache manifest (http://www.myapp.com/app/mobile/cache.manifest.php) into the browser the file is displayed correctly but when I try to load the page once offline I get the "Unable to connect" error page. Again, that just happens on Firefox and Opera.
Firebug says "0 items in offline cache" and I didn't find the way to check the application cache on DragonFly.
I am getting mad and I don't know how to debug the problem effectively on Firefox and Opera.
Please help.
Thanks,
Dan
In my experience using the HTML5 AppCache, it is great once you get it working, but extremely brittle. If there's the tiniest thing wrong with it the browser ignores the entire file and, annoyingly, rather than use the browser's ordinary cache, re-loads everything from scratch off the server.
Worse, browsers will not re-load the manifest file unless its text content changes. So you might tweak your server headers or something to fix it, but unless the content of cache.manifest.php changes the browser will blindly ignore it and do exactly what it did last time. So it could have been broken, then you fixed it, but browsers are ignoring the changes because the text content of cache.manifest.php hasn't changed. This even seems to be immune to clearing your browser cache, which is part of what makes it so confusing - app cache is really, really serious about caching.
To get around this, text changes in comments count, so have a comment at the top with a version or timestamp or the date (e.g. # Version 1.2) and change that when you want the browser to "notice".
Then, the browser still won't immediately use it! The way the app cache works is the next time you load the page it will do exactly what it did last time yet again, and start checking for an update in the background. So you probably want the console up, wait for something like "updating..." then "complete", then hit Refresh and the browser will finally start using the new version. At last!
All in all it can be a right pain to get working. However, once it's working it's almost bulletproof: you can pretty much rest assured anything listed in the cache manifest is only every downloaded once, ever, for all time, per user, until you change the text content of the file.
Browser standards compliance is pretty good these days, so my best guess is you actually have it working, but you checked Chrome last and it's the only browser which has cached the manifest file correctly. During development you might have had it broken, but Firefox and Opera are clutching their old manifest files to the death. I bet you also tried clearing the browser cache in Firefox and Opera, which probably did nothing - you need to change the text content of the file and double-refresh before either Firefox and Opera will finally give up their broken versions of the manifest file and start using the one which works which you probably uploaded ages ago.
From: http://appcache.offline.technology
In Firefox, any resources served with Cache-control: no-store will not be cached, even if they're explicitly included in the manifest.
My php by default is sending:
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
It is enough to add:
header("Cache-Control: no-cache, must-revalidate");
To the php file to get it to start caching it.
(This is similar to Mychal Hackman's answer, but a little more specific).
To me your cache manifest looks a bit "unusual"... it might help to add a FALLBACK section... another point is that the appcache might interfer with the "normal browser cache" i.e. if the cache manifest is changed it needs to make sure that the browser reloads it, ideally this is achieved by changing the name (for example by having version number, timestamp... as part of the name).
You can interact in your page with the appcache via JS which could help to pinpoint the problem you see.
For in-depth information including JS code and a thorough walk-through see
http://www.html5rocks.com/en/tutorials/appcache/beginner/
http://www.w3.org/TR/html5/offline.html
If need be come back with specific questions.
UPDATE
As per comments provided by OP this shows a nice implementation of the JS API for checking/debugging appcache as described in the links above.
You can check the current status of the application cache using window.applicationCache.status, which returns a numeric value mapped to the following states:
0 - uncached, 1 - idle, 2 - checking, 3 - downloading, 4 - updateready, 5 - obsolete.
The application cache API has a few things worth noting:
window.applicationCache.update(): This will trigger the application cache download process, which is nearly the same as reloading the page. It simply checks if the manifest has changed, and if so downloads a fresh version of all the content in the cache (respecting any cache headers). Note that even though a new cache is created with this, the page will continue to use the old cache. To make the page use the new cache you have just downloaded, you must use the swapCache() function.
window.applicationCache.swapCache(): This function tells the browser to start using the new cache data if it is available. It is important to note that even if there is a new manifest file, the application will still continue using the old cache (as specified in the old manifest file) untill swapCache() is called. Once swapCache() is called, then the cache will be used as specified from the new manifest file.
from: http://dev.opera.com/articles/view/offline-applications-html5-appcache/
Check your cache in about:cache. I am betting you will see "data-size 0 bytes" for your PHP file(s).
Check your caching headers, I found in Firefox the default was "no-cache" on my php files. I just added:
header("Pragma: public");
header("Cache-Control: public, max-age=6000");
to my PHP file and reloaded the offline cache and it is finally working.
HTH
Try removing:
header("Cache-Control: max-age=0, no-cache, no-store, must-revalidate");
header("Pragma: no-cache");
header("Expires: Wed, 11 Jan 1984 05:00:00 GMT");
so that you are only sending the Content-type header:
<?php header('Content-type: text/cache-manifest'); ?>
ApplicationCache forces caching (oversimplifying, but not by much). Those first three headers are ways to prevent caching.
Opera appears to prevent caching when those headers are present. Firefox' debugging tools are a bit wonky when it comes to debugging AppCache, but it's probably save to assume this will fix it there as well.
For Firefox, try this little trick:
<html manifest="/app/mobile/cache.manifest.php?1">
Its the "?1" that finally get Firefox to check for the latest file. That's what did the trick for me anyway. Hope this helps.
From my experience with getting a site working offline on the iPad:
The name of the file needs to end with .manifest
The mime type needs to be text/cache-manifest
Have a version in the comments of your manifest
Create some javascript functions using window.applicationCache... to check if the browser sees a change in the manifest and to reload the content, also capture the status events and display them somewhere
See also:
http://developer.apple.com/library/safari/#documentation/iPhone/Conceptual/SafariJSDatabaseGuide/OfflineApplicationCache/OfflineApplicationCache.html#//apple_ref/doc/uid/TP40007256-CH7-SW1
I had a similar problem. I am very late in answering but this might be helpful for others. Make sure you dont run into problems described by AshleysBrian in his answer. Adding to that
Make sure the manifest file is served as type "text/cache-manifest"
Dont try it out in Private Browsing mode in Firefox/IE. It only works in regular browsing mode. But it works in both modes in Chrome
While offline, a simple change in the URL could be a problem
Eg: http://localhost:8080/app doesn't work on Firefox/IE
but http://localhost:8080/app/ works in Firefox/IE
Both of them work in Chrome
Use these handy resource viewers to get more detailed perspective
about:cache - Firefox
chrome://appcache-internals/ - Chrome
Pls fill in if someone knows what is it for IE
As I understand, the Offline Web applications section in the W3C HTML5 draft is non-normative; meaning that is it still not part of the formal HTML5 standard as yet.
Since the feature is still not part of the HTML5 standard, different browsers may have different and varying/non-standard implementations, if at all they choose to implement it. Not all browsers may choose to support it. Do not rely on non-normative features until they are part of the standard.
I've found something similar, and tracked it down to the Cache-Control: no-store heading on the manifest. Chrome accepts this, but Firefox fails silently with this.
My tests showed that you can keep no-cache headers & expires headers in to ensure frequent refreshes.
My only way to make the manifest work everywhere is to do this:
CACHE MANIFEST
# version x.x
# 2015-03-27
# list everything
If I use NETWORK and/or FALLBACK it wont work (in Chrome).
I had the same problem also. Everything worked fine in Chrome and IE, but an "Unable to connect" message in FF.
After hours of despair, i found the solution and it was ridiculous simple:
In the developer-toolbar the entire cache was deactivated.
:/