How to prevent html5 page from caching?
I converted a plain vanilla HTML page to HMTL5/CSS3 with a responsive layout, and for security reasons (dictated by the security people) the page must never cache. The page previously used and to prevent the page from being cached. What replaces this in HTML5? How do you prevent an html page from caching in the client? I’ve spent a week reading about manifest files, but they seem to do exactly opposite of what I want as attaching a manifest file explicitly causes the page it is attached to to cache. And please don’t refer me back to the w3c definition of which meta elements are now allowed — I understand that HTML5 does not include the cache-control or Pragma in meta elements. I need to know what it does include that will prevent a page from being cached.
4 Answers 4
In the beginning of code you need to use this:
Then create manifest.appcache with such content:
CACHE MANIFEST # Cache manifest version 1.0 # no cache NETWORK: *
Thanks, that work to prevent the file from caching, but now it pops up a info bar in Firefox stating: «This web site is asking to store data on your computer for offline use.» Which again is exactly the opposite of what I want to happen. Very annoying and will not be too user friendly for our novice users — we cater to healthcare professionals who are less than Internet savvy. Anyway to keep the manifest and ditch the info bar or is this just the way it is with firefox?
an equivalent solution is to reference a manifest file that doesn’t exist: but this will show up in the console in chrome developer tools.
This feature has been removed from the Web standards. Though some browsers may still support it, it is in the process of being dropped. Avoid using it and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time. developer.mozilla.org/en-US/docs/Web/HTML/…
I dislike appcache a tremendous amount. It almost works well but can be a real unforgiving pain. While doing some code refactoring, I realized that after logout, i could browse back to the the last page. Of course, refreshing browser it would force user back to login but this is not desired.
After searching around and seeing the options, I started to get a bit frustrated. I do not want to use appcache. I then realized that my code was redirecting to login page after destroying the session and got an idea, what if, I redirect to the home page instead? And voila, page was loaded, session checked (and of course not there), user redirected to login. Problem solved.
I have been struggling with the same issue for quite some time. What works for me — at least so far — in Chrome, FF and IE is doing the following:
1) reference the manifest file From what I understand, this will cache everything that follows in this HTML document, hence a manifest file is needed to prevent this from happening:
2) use a manifest file filename.appcache with the following content which basically says: for all files, do not read from cache but from network server:
CACHE MANIFEST # 2015-09-25 time 20:33 UTC v 1.01 NETWORK: * 3) a third step is required: each time you upload a (partial) update of your website, also change the manifest file by changing the date and time stamp in the comment(#) line. Why? Because if you do not change the manifest file, it will not be read and it will default to step 1 and thus cache and read from cache. The fact that the manifest file is changed, however, enforces the manifest file to be read again, and thus enforces that the «do not read from cache but read from network server» instruction therein, is applied again.
The previous answer may not consistently work to prevent caching or to clear existing cache in chrome but there is a work around.
1) To clear existing cache in chrome, it may be necessary to update all files of the website (eg by linking to a new css file on every page) along with an update of the cache-manifest before existing cache in chrome gets cleared upon the second visit of a page (because of the «flow» of the way in which a page is rendered: the first time a page is visited, the browser reads and caches the manifest , while proceeding with loading from existing cache. Only upon the second visit will the newly stored updated manifest be read and applied).
2) and if none of that helps, it is possible to include a script in the manifest file itself to check for a new manifest and if found, reload it and use the new manifest. This did the trick and resolved all remaining cases I tested for where files had remained persistently cached in chrome. I found this script on this page by Jason Stimpel.
How to prevent caching in Internet Explorer
The retired, out-of-support Internet Explorer 11 desktop application has been permanently disabled through a Microsoft Edge update on certain versions of Windows 10. For more information, see Internet Explorer 11 desktop app retirement FAQ.
This article describes the use of HTTP headers to control the caching of Web pages in Internet Explorer.
Original product version: Internet Explorer
Original KB number: 234067
Summary
You can use Microsoft Internet Information Server (IIS) to easily mark highly volatile or sensitive pages using the following script at the extreme beginning of the specific Active Server Pages (ASP) pages:
Expiration and the Expires header
It’s highly recommended that all Web servers use a scheme for the expiration of all Web pages. It’s a bad practice for a Web server not to supply expiration information via the HTTP Expires response header for every resource returned to requesting clients. Most browsers and intermediate proxies today respect this expiration information and use it to increase the efficiency of communications over the network.
Always use the Expires header to specify the most reasonable time when a particular file on the server needs to be updated by the client. When pages are updated regularly, the next period for update is the most efficient response. Take, for example, a daily news page on the Internet that is updated every day at 5 A.M. The Web server for this news page should return an Expires header with a value for 5 A.M. the next day. When it’s done, the browser doesn’t need to contact the Web server again until the page has changed.
Pages that aren’t expected to change should be marked with an expiration date of approximately one year.
In many cases, Web servers have one or more volatile pages on a server that contain information that’s subject to change immediately. These pages should be marked by the server with a value of «-1» for the Expires header. On future requests by the user, Internet Explorer usually contacts the Web server for updates to that page via a conditional If-Modified-Since request. However, the page remains in the disk cache (Temporary Internet Files). And the page is used in appropriate situations without contacting the remote Web server, such as:
- when the BACK and FORWARD buttons are used to access the navigation history.
- when the browser is in offline mode.
The Cache-Control header
Certain pages, however, are so volatile or sensitive that they require no disk caching. To this end, Internet Explorer supports the HTTP 1.1 Cache-Control header. This header prevents all caching of a particular Web resource when the no-cache value is specified by an HTTP 1.1 server.
Pages that are kept out of the cache aren’t accessible until the browser can recontact the Web server. So, servers should use the Cache-Control header sparingly. In most cases, the use of Expires: -1 is preferred.
The Pragma: No-Cache header
Unfortunately, legacy HTTP 1.0 servers can’t use the Cache-Control header. For purposes of backward compatibility with HTTP 1.0 servers, Internet Explorer supports a special usage of the HTTP Pragma: no-cache header. If the client communicates with the server over a secure connection ( https:// ) and the server returns a Pragma: no-cache header with the response, Internet Explorer doesn’t cache the response.
However, the Pragma: no-cache header wasn’t for this purpose. According to the HTTP 1.0 and 1.1 specifications, this header is defined in the context of a request only, not a response. It’s intended for proxy servers that may prevent certain important requests from reaching the destination Web server. For future applications, the Cache-Control header is the proper means for controlling caching.
HTTP-EQUIV META tags
HTML pages allow for a special HTTP-EQUIV form of the META tag that specifies particular HTTP headers from within the HTML document. Here’s a short example HTML page that uses both Pragma: no-cache and Expires: -1:
Pragma: no-cache prevents caching only when used over a secure connection. A Pragma: no-cache META tag is treated identically to Expires: -1 if used in a non-secure page. The page will be cached but marked as immediately expired.
Cache-Control META HTTP-EQUIV tags are ignored and have no effect in Internet Explorer versions 4 or 5. To use Cache-Control, this header must be specified using HTTP headers as described in the Cache-Control section above.
The use of standard HTTP headers are much preferred over META tags. META tags typically must appear at the top of the HTML HEAD section. And there’s at least one known problem with the Pragma HTTP-EQUIV META tag.
Server options for caching
When the Cache-Control header needs to be used on non-ASP pages, it may be necessary to use options in the server configuration to add this header automatically. For the process of adding HTTP headers to server responses for a particular directory, refer to your server document. For example, in IIS 4, follow these steps:
- Start the IIS Manager.
- In the computer and services tree, open the Default Web Server, or the web server in question. Find the directory containing the content that needs the Cache-Control header.
- Open the Properties dialog for that directory.
- Select the HTTP Headers tab.
- Select the Add button in the Custom HTTP Headers group, and add Cache-Control for the header name and no-cache for the header value.
It’s not a good idea to use this header globally across the entire Web server. Restrict its use purely to content that absolutely mustn’t be cached on the client.
Problem checklist
If you’ve applied the techniques in this article and you’re still having problems with caching and Internet Explorer, review this handy checklist step by step before contacting Microsoft for technical support assistance:
- Are you using the Cache-Control header with the ASP Response.CacheControl property or through a returned HTTP header? It’s the only way to truly prevent caching in Internet Explorer.
- Are you using Internet Explorer 4.01 Service Pack 2 or higher? There’s no way to completely prevent caching in earlier versions of the browser.
- Have you double-checked that your web server has HTTP 1.1 turned on and is returning HTTP 1.1 responses to Internet Explorer? Cache-Control headers are invalid in HTTP 1.0 responses.
- If you’re using CGI/ISAPI/Servlets on the server side, are you following the HTTP 1.1 specification exactly, particularly about CRLF termination of HTTP headers? In the interest of performance, Internet Explorer is typically unforgiving of responses that violate the HTTP 1.1 specification. It usually results in ignored headers or reports of unexpected server errors.
- Are the HTTP headers spelled correctly?