Regarding the principle and implementation of HTML5 offline storage, the author found an introduction to offline caching. It feels more thorough than the explanation I saw before. The new knowledge points are recorded as follows:
Everyone knows that Web Apps are accessed through browsers, so offline The app cannot be used in this state. Some of the resources in the web app do not change frequently and do not need to send requests to the server every time. At this time, the offline cache that came into being is particularly prominent. By listing the files that need to be cached offline in a manifest configuration file. This way you can use the app even offline.
The manifest stored offline generally consists of three parts:
1. CACHE: Indicates the list of resources that need to be stored offline. Since the page containing the manifest file will be automatically stored offline, there is no need to list the page itself.
2.NETWORK: Indicates that the resources listed under it can only be accessed online, they will not be stored offline, so these resources cannot be used offline. Shangxuetang • Baizhan programmer Mr. Chen pointed out that if there is a same resource in CACHE and NETWORK, this resource will still be stored offline, which means that CACHE has a higher priority.
3.FALLBACK: Indicates that if accessing the first resource fails, then use the second resource to replace it. For example, the above file indicates that if accessing any resource in the root directory fails, then go to offline.html. Using HTML5, offline versions of web applications can be easily created by creating a cache manifest file.
HTML5 introduced application caching, which means that web applications can be cached and accessed without a network.
Application caching brings three advantages to applications:
Offline browsing - Users can use them when they are offline.
Speed - resources that are already cached load faster.
Reduce server load -- the browser will only download changed resources from the server.
Principle and Environment
As mentioned above, the offline storage of HTML5 is based on a newly created .appcache file. Resources are stored offline through the parsing list on this file, and these resources will be stored like cookies. Later, when the network is offline, the browser will display the page through the data stored offline. Just like cookies, offline storage of HTML5 also requires a server environment. Here is a small tool - simple iis server, put it in the project directory, double-click to run to simulate the server environment.
Parsing list
Before you start, you must first understand the manifest (ie. appcache file) and how to write the above parsing list. A manifest file is a simple text file that tells the browser what to cache (and what not to cache).
The manifest file can be divided into three parts:
CACHE MANIFEST - files listed under this heading will be cached after the first download;
NETWORK - files listed under this heading require a connection to the server and will not be cached;
FALLBACK - The files listed under this heading specify the fallback page (such as a 404 page) when the page is unreachable; in
the online case, the user agent will read the manifest every time the page is accessed. If it finds a change, reload all resources in the manifest.
The first line, CACHE MANIFEST, is required:
1 CACHE MANIFEST / theme.css /logo.gif / main.js
The manifest file above lists three resources: a CSS file, a GIF image, and a JavaScript file. When the manifest file loads, the browser downloads these three files from the root directory of the website. These resources are then available whenever the user is disconnected from the Internet.
NETWORK
whitelist, use the wildcard "*". It will enter the open state of the whitelist. In this state, all URLs that do not appear in the relevant Cache area will use the HTTP-related cache header policy by default.
The following NETWORK section specifies that the file "login. asp" is never cached and unavailable offline:
1 NETWORK: login.asp
can use * to indicate that all other resources/files require an Internet connection:
NETWORK: *
FALLBACK
The FALLBACK subsection below specifies that if the Internet cannot be established link, replace all files in the /html5/ directory with "offline.html":
ALLBACK: /html5/ /404.html
Note: The first URI is the resource, the second is the replacement.
For the browser, the manifest is loaded later than other resources. This causes the check manifest process to be laggy. It is found that the manifest changes. All browser implementations follow this to silently update resources. To ensure the following The second pv, applied to the update. Our product has been updated, but users can see it only after coming in for the second time, so the user experience is too bad, is there any way to solve it? Fortunately, html5 provides relevant APIs to javascript.
The capacity limit of the offline storage of the site is 5M. If the manifest file, or one of the files listed inside cannot be downloaded normally, the entire update process will be regarded as a failure, and the browser will continue to use the old cache. The html that refers to the manifest must be the same as the manifest file. Source, in the same domain, the relative path used in the manifest, the relative reference is the manifest file, the CACHE MANIFEST string should be in the first line, and is essential, the system will automatically cache the HTML file referencing the manifest file. The CACHE in the manifest file has nothing to do with the position order of NETWORK and FALLBACK. If it is an implicit declaration, it needs to be at the top.
The resource in FALLBACK must be of the same origin as the manifest file. When a resource is cached, the browser will also access the resource in the cache by directly requesting this absolute path. Even if other pages in the site do not set the manifest attribute, the requested resources are accessed from the cache if they are in the cache. When the manifest file changes, the resource request itself will also trigger an update.