To do this, use the cache as much as possible, often getting the previous message from the cache. Fortunately, most WAP devices now have a certain level of caching, which, by default, tries to maximize the cache. Almost all responses to URLs are cached.
As defined by [RFC2616], caching is the "local storage area of the response message in the program and the subsystem that controls the storage, retrieval, and deletion of these messages." The cache saves response messages that can be cached in order to reduce future response times and network bandwidth consumption, as well as request messages. "
When the WAP user terminal caches a response, it saves almost all information: URL, response text, message header, and other content that can validate the response (see the next section, "Validation and History stacks"). Each cached item can be uniquely identified based on its URL component (domain name, path, protocol, parameters, port, and so on).
There are two types of HTTP headers that let you control the deck cache of WML, and the most important thing for us is the Cache-control message header. It can control all the cached entities directly through the request/response chain. All caching mechanisms must adhere to the definition of these headers. The Cach-control message header is typically used to mask the default caching behavior of a device. They must pass through all proxy servers and gateways without being altered in the message chain.
<meta http-equive= "Expires" content= "Mon, 00:00:00 GMT"/>
<meta http-equive= "Cache-control" content= "max-age=300"/>
<meta http-equive= "Cache-control" content= "No-cache"/>
* Cache-control:no-cache. The URL that sets this option cannot be cached, including the user terminal and all other servers between the content server and the user terminal;
* cache-control:max-age=<second>. Defines a URL that guarantees the maximum time in the device cache. When the time is up, the entity clears from the cache;
* expired:<date>. Specifies the last date period on which the URL is stored in the cache. [RFC1123] Defines the format of the date, usually as follows: Expires:sun, October 17:30:47 GMT
When writing a WAP application, you should assume that the user terminal will maximize caching to minimize the movement of information to the content server. Here are some explanations:
1. Permanent Cache URL
The WAP user terminal usually keeps the URL in its cache for as long as possible, and this "as long as possible" definition in the Phone.com browser is about 30 days. However, you may want to keep the cache time of a URL as long as possible, such as your company's logo, so that each time you open the page will be reduced. The following two ways can be easily implemented:
* Specify a very far from the expiration date, such as: Expires:tue, 2002 00:00:00 GMT;
* Specify a large cache time, such as: cache-control:max-age=3153600. This example allows the URL to be cached for one year. The maximum number of integers allowed for a user terminal is 2,147,483,647, so you can keep a URL for more than 68 years. Of course, by that time, your mobile phone was already scrapped.
2, specify the cache time for the URL
Usually the case is for a URL you just need to cache for a while. For example, the stock quotes system, the Web page may need 5 minutes to update, then you only have to deck in the head part of the designated cache-control:max-age=300 on the line. If the user retrieves the page again within 5 minutes, see the page in the cache. If you are in 5 minutes, you will get the most current data on the server.
Another way to control the caching time is to use the expires mentioned earlier, but this method only tells the user that the terminal is refreshed whenever a specified time is passed, regardless of when the page is accessed. If you want to control time, you can only change the time value in expires.
3, prohibit the caching of the URL
For fast-changing content, it is generally desirable to get the latest data every time. So this time to completely prohibit the caching of related Web pages. There are three kinds of methods:
* Set Cache-control:no-cache;
* Set maximum cache time for 0,cache-control:max-age=0;
* Set cache expiration date for a long time past, Expires:mon, 1 1990 00:00:00 GMT.
In fact, the latter two are not the best choice. First of all, this will take up more of the terminal processing time, because when you encounter this deck, the terminal needs to calculate the expiration time. Second, this would take up a bit more bytes and not be clear enough in the expression.
WAP standards stipulate that all WAP devices should have a history stack of at least 10-item capacity. When the user presses the forward (forward) link defined by the <go> or other steering instruction, the URL is pushed (push) into the stack. If you press the back (backward) link defined by <prev>, the URL is bounced (pop).
In general, all the forward links are validated, and the back link is not, because it is already in the cache. But we sometimes hope that when the user presses the Back button, they still get the latest data. If the terminal is always not validated, the user has to find the main menu and re-enter the page.
Fortunately, we use cache-control:must-revalidate to force the user terminal to authenticate the URL when the user presses back. Of course, validation does not mean that the page will be reread immediately, but that it is based on whether or not it expires. If it does not expire, the result of the validation is still to display the page in the cache.
If you need to re-read the page each time back, use Cache-control:must-revalidate, No-cache can be implemented. In addition, replacing No-cache with max-age=300 can refresh a page that has been cached for 300 seconds on the back.
