With the above foundation, I believe everyone can do a lot of things. Now let's go into the deeper and see how to improve performance and network transmission efficiency. First, we need to introduce the basic knowledge of http 1.1 (RFC2616). Of course, if you are already familiar with it, you can skip the first part.
1. A brief introduction to HTTP 1.1
HTTP 1.1 is a mainstream protocol for text-based Internet entity information interaction. The entity here can be a user terminal such as a WAP compatible browser, a proxy server such as a WAP gateway, or aJavaSource server programs such as servlets. The interaction information between them is two categories: client request to server side and server response to client side. A complete interaction includes a request and a response to it.
All requests and responses are in the standard Internet message format defined in [RFC822], and the framework is as follows:
* Message definition
* No or multiple headers
* CRLF (blank line input)
* Optional message body
The message definition specifies the type of message sent. Both the request and the response may contain multiple message headers to further or redefine the interaction between the user terminal and the server. CRLF is only used to separate the information definition from the message ontology.
1. Request
In the message definition section, you can define the request as follows: Request type URL HTTP/1.1
The request type can be one of the following:
①. OPTION: Returns the communication options that can be used between the requester and the corresponding person, mainly used to detect server processing capabilities;
②. GET: Obtain the file content or program execution results marked with URL. The server determines the service content based on the file name suffix, such as whether the URL is static text or a program;
③. HEAD: Except for not returning the response information body, what you get is the same information as GET. Generally used to test the effectiveness, accessibility and recent modifications of links;
④. POST: Send messages in the message body to a URL or other similar server-side definition behavior. It is usually used to submit an HTML form or some data operation activities;
⑤. PUT: Send messages in the message body to a URL, similar to POST, but are not commonly used;
⑥. DELETE: Delete the resource specified by the URL;
⑦. TRACE: Calls a remote application layer request message loop. In addition to receiving the original message content, the user terminal sending this message also obtains the transmission path of the message on the Internet.
The most commonly used request types - and what we care most about when dealing with WAP applications - are GET and POST. Suppose there is a WML document and we use UP browser to browse it, we will issue the following GET request to the server:
GET /wap/ HTTP/1.1
accept-charset: UTF-8
accept-language: ch
accept: text/, */*, image/bmp, text/html
user-agent: /3.1-UPG1 /3.2
host:
……
The bold part is the HTTP message header, here we ignore some message headers that have little to do with us.
accept-charset:Character sets supported by user terminals
accept-language:The language currently used by the user terminal
accept:MIME file types that are acceptable to the user terminal
user-agent:Terminal description information provided by user terminal supplier
host:The domain name to which the request information is sent
2. Response
The message definition part of the response is generally as follows: HTTP/1.1 status code Status description defines nearly 40 different status codes (divided into 5 groups) in [RFC2616]. The most common ones are 3:
200 OK
401 Unauthorized
404 Not Found
Continuing with the example above, if the URL is legal, the server's response would be like this:
HTTP/1.1 200 OK
Server: www/5.0
Date: Fri, 26 Oct 2000 12:15:23 GMT
Connection: Keep-Alive
Content-Length: 1211
Content_Type: text/
Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT
<?xml version=”1.0”>
<!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”
“/DTD/wml_1.”>
……
Other content
……
This response information includes the response's numeric code and text description, followed by a set of message headers. After a newline, it is the message body, where the message body is the source code of /.
Server:The server that issued the response
Date:Time of response sent
Connection:Instruct the user terminal to remain connected
Content-Length:The length of the response information is calculated from the first "<" character of the DECK
Content_Type:Responsive MIME type
Last-Modified:The last modification time of DECK in response
When the user terminal receives the response, it will decode its status information and message header, and then decide what actions to do to the response. If you receive an OK response, the content in the message body will generally be displayed on the screen. For desktop terminals, it is usually HTML, and for WAP browsers, it is WML.
HTTP is a very tedious protocol. Even simple requests and responses without any data will generate hundreds of bytes of messages. WAP solves this problem through the WAP gateway. A very important function of WAP gateway is to convert all HTTP1.1 messages into the message format of Wireless Session Protocol (WSP). This format is a compressed binary protocol and is compatible with HTTP 1.1. It parses all request and response messages and converts them into the most streamlined BIT sequence.
At this point, we have introduced the main contents of HTTP 1.1. Of course, HTTP 1.1 still has a lot of complex content, but I don’t plan to talk about it here. If you are interested, you can go to the relevant website to find its information. The author just wants everyone to know one thing: there are more interactive messages between the user terminal and the server than GET and POST requests. They also have request and response message headers, and can contain some signals to affect the execution and performance of WAP applications. This is the secret to improving WAP operation efficiency.
2. Caching
According to the definition of [RFC2616], the cache is: "The local storage area of response messages in the program and the subsystem that controls the storage, re-acquisition and deletion of these messages. The cache saves the response messages that can be cached to reduce future response time and network bandwidth consumption, and is also applicable to request messages."
Due to the limitation of WAP channel bandwidth, we all hope to minimize the number of messages when writing WAP applications. To do this, try to use the cache as much as possible and get previous messages from the cache frequently. Fortunately, most WAP devices currently have a certain level of cache, and by default, they will try to maximize cache. Almost all responses to URLs are cached.
When a WAP user terminal caches a response, it saves almost all information: URL, response text, message headers, and other content that can verify the response (see the next section "Verification and History Stack"). Each cached item can be uniquely identified according to its URL components (domain name, path, protocol, parameters, port, etc.).
There are two types of HTTP headers that allow you to control the DECK cache of WML. The most important thing for us is the Cache-Control header. It can control all cache entities directly through the request/response chain. All caching mechanisms must comply with the definition of these message headers. The Cach-Control message header is usually used to block a device's default cache behavior. They must pass directly through all proxy servers and gateways when they are delivered in the message chain without being changed.
* 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>
* Expired:<date>
When writing a WAP application, you must first assume that the user terminal will try to maximize the cache so as to minimize the action of obtaining information from the content server. Here are some explanations:
1. Permanently cache URL
WAP user terminals usually try to save accessed URLs in their cache as long as possible. The definition of this "shoulder as long as possible" in the browser is about 30 days. However, maybe you want to extend the cache time of a URL as long as possible, such as your company's LOGO, so that the time you open the page will be reduced each time. The following two methods can be implemented very simply:
* Specify an expiration date far from now, for example: Expires: Tue, 01 Jan 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 integer allowed by the user terminal is 2,147,483,647, so you can have a URL saved for more than 68 years. Of course, by that time, your phone would have been scrapped.
2. Specify the cache time for the URL
It is usually the case that for a URL you only need to cache for a period of time. For example, in the stock quotation system, the web page may need to be updated every 5 minutes, so you just need to specify Cache-Control: max-age=300 in the HEAD part of DECK. If the user searches the page again within 5 minutes, he or she will still see the web page in the cache. If it is 5 minutes later, the latest data will be obtained on the server.
Another way to control cache time is to use Expires mentioned above, but this method can only tell the user terminal: as long as the specified time has passed, the page must be refreshed no matter when it is accessed. If you want to control the time next time, you can only change the time value in Expires.
3. Disable URL cache
For content that changes rapidly, you generally want to get the latest data every time. Therefore, caching of related web pages must be completely prohibited at this time. There are three methods:
* Set Cache-Control: no-cache;
* Set the maximum cache time to 0, Cache-Control: max-age=0;
* Set the cache expiration date to a long time ago, Expires: Mon, 1 Jan 1990 00:00:00 GMT.
In fact, the latter two are not the best choice. First of all, this will take up more processing time of the terminal, because when encountering this DECK, the terminal needs to calculate the expiration time. Secondly, this will take up more bytes and it is not clear enough in terms of expression.
3. Verification and History Stack
The concept of verification is further proposed for caching in HTTP 1.1. The purpose of verification is to verify whether the cache item is within the validity period. Due to the existence of the history stack, the verification process on the WAP terminal becomes a bit complicated.
The WAP standard stipulates that all WAP devices must have a historical stack that can accommodate at least 10-items. When the user presses by <go>
Generally, all forward links will be verified, while back links will not, because it is already in the cache. But sometimes we still hope that when the user presses the back button, we can still get the latest data. If the terminal always fails to verify, 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 verify the URL when the user presses the back. Of course, verification does not mean that the page will be reread immediately, but rather it will be determined based on whether it expires. If it does not expire, the verification result is still the page in the cache.
If you need to reread the page every time the back, you can do it with Cache-Control: must-revalidate, no-cache. In addition, changing no-cache to max-age=300 can refresh the page that has been cached for 300 seconds on the back.
4. HTTP header and meta elements
At this point, everyone already knows the role of HTTP message headers on WAP pages. However, to set these message headers in the WML document, you need to use the meta element, which can only appear in the <head> section of the WML document. Here are several message headers and their representations:
Expires: Mon, 10 Jan 2000 00:00:00 GMT
Cache-Control: max-age=300
Cache-Control: no-cache
<meta http-equive="Expires" content=" Mon, 10 Jan 2000 00:00:00 GMT"/>
<meta http-equive="Cache-Control" content="max-age=300"/>
<meta http-equive="Cache-Control" content="no-cache"/>
When the gateway scans elements in the WML document, it will convert them into WSP-equivalent HTTP message headers, and the user terminal can control the cache accordingly.