关于缓存(cache) 
有了初级教程的基础，置信大家曾经能够做不少事情了。在本章，我们来深入一下，看看如何提高功用和网络传输效率。首先，需求引见一下http 1.1（RFC2616）的基础知识。当然，如果你曾经很熟悉了，可以跳过第一节。

一、HTTP 1.1的简要引见  
请求 呼应 
二、缓存(cache)  
永世缓存URL  指定对URL的缓存时间 禁止对URL的缓存
三、验证（validation）和历史堆栈（History Stack）
四、HTTP头与meta元素  


一、HTTP 1.1的简要引见 [TOP]
HTTP 1.1是一个基于文本的互联网实体信息交互主流协议，这里的实体可以是WAP兼容浏览器之类的用户终端，可以是WAP网关之类的代理服务器，也可以是Java servlet之类的源服务器程序。它们之间的交互信息就是两大类：客户端对服务器端的请求（request）和服务器端对客户端的呼应（response）。一次完整的交互包括一个请求和对它的呼应。

所有的请求和呼应都采用[RFC822]中定义的标准互联网音讯格式，框架如下：
* 音讯定义
* 没有或多个音讯头
* CRLF（空行回车）
* 可选的音讯本体
其中音讯定义不分指定了发送音讯的类型。请求和呼应都可以包含多个音讯头，用来进一步或者重新定义用户终端和服务器之间的交互。CRLF仅仅用来将信息定义和音讯本体分开。

1、 请求 [TOP]
在音讯定义部分可以这样定义请求： 请求类型 URL HTTP/1.1
其中请求类型可以是下面的一种：
①. OPTION：前往请求者和相应者之间可以使用的通信选项，次要用来检测服务器处理能力；
②. GET：获得以URL标示的文件内容或者程序执行结果。服务器依据文件名后缀判断服务内容，比如该URL是静态文本还是一个程序；
③. HEAD：除了不前往呼应的信息本体以外，得到的是跟GET一样的信息。普通用来测试链接的无效性、可达性和近期修正；
④. POST：把音讯本体中的音讯发送到一个URL或者其他类似的服务器端定义行为。通常用来提交一个HTML表单或者一些数据操作活动；
⑤. PUT：把音讯本体中的音讯发送到一个URL，跟POST类似，但不常用；
⑥. DELETE：删除URL指定的资源；
⑦. TRACE：调用一个近程使用层请求音讯回路。发出这个音讯的用户终端除了收到原来的音讯内容以外，还得到音讯在Internet上的传送路径。
最常用的请求类型--也是我们在处理WAP使用时最关怀的--是GET和POST。假设有一个WML文档，我们用UP的浏览器去浏览的话，就会向服务器发出如下GET请求：
GET www.wap86.com/index.wml HTTP/1.1
accept-charset: UTF-8
accept-language: ch
accept: text/vnd.wap.wml, */*, image/bmp, text/html
user-agent: UP.Browser/3.1-UPG1 UP.Link/3.2
host: www.wap86.net
……
其中粗体的部分是HTTP音讯头，这里我们忽略了一些与我们关系不大的音讯头。
accept-charset: 用户终端支持的字符集
accept-language: 用户终端目前使用的言语
accept: 用户终端可以接受的MIME文件类型
user-agent: 用户终端供应商提供的终端描述信息
host: 请求信息发送到的域名

2、 呼应 [TOP]
呼应的音讯定义部分普通是这样的：HTTP/1.1 形状码 形状描述 在[RFC2616]中定义了近40种不同的形状码（分成5组）。其中最常见的是3个：
200 OK
401 Unauthorized
404 Not Found

继续上面那个例子，如果该URL合法的话，服务器的呼应会是这样的：
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/vnd.wap.wml
Last-Modified: Mon, 22 Oct 2000 18:19:24 GMT

<?xml version=”1.0”>
<!<!DOCTYPE wml PUBLIC “-//WAPFORUM//DTD WML 1.1//EN”
“http://www.wapforum.org/DTD/wml_1.1.xml”>

……
其它内容
……

这个呼应信息里包括了呼应的数字代码和文本描述，然后是一组音讯头。在一个换行符当前就是音讯本体，在这里，音讯本体就是www.wap86.net/index.wml的源代码。
Server: 发出呼应的服务器
Date: 呼应发出的时间
Connection: 指示用户终端保持连接
Content-Length: 呼应信息的长度，从DECK的第一个"<"字符开始计算
Content_Type: 呼应的MIME类型
Last-Modified: 呼应中DECK的最后修正时间

当用户终端接收到呼应当前，会对其形状信息和音讯头进行解码，然后决定对呼应做出什么样的动作。如果收到OK呼应，普通会把音讯本体里的内容显示在屏幕上。对于桌面终端，通常是HTML，对于WAP浏览器，则是WML。

HTTP是一种很罗嗦的协议。即便是简单没有任何数据的请求和呼应都要产生数百字节的音讯。WAP通过WAP网关来处理这个问题。WAP网关一个很重要的功用就是把所有的HTTP1.1音讯转换成无线任务协议（Wireless Session Protocol, WSP）的音讯格式。这种格式是紧缩的二进制协议，兼容HTTP1.1。它能解析所有的请求和呼应音讯，并转换成最精简的BIT序列。

到这里我们曾经引见了HTTP1.1的次要内容。当然HTTP1.1还有很多复杂的内容，但是在这里并不打算多讲，如果你有兴味，可以去相关网站查找它的材料。作者只想大家知道一点：用户终端和服务器之间还有比GET和POST请求更多的互动音讯，它们一样有请求和呼应音讯头，并且可以包含一些信号来影响WAP使用程序的执行和功用。这正是提高WAP运转效率的秘密所在。

二、缓存（Caching） [TOP]
依据[RFC2616]的定义，缓存是："程序中呼应音讯的本地储存区以及控制这些音讯储存、重新获取和删除的子系统。缓存保存可以缓存的呼应音讯以便降低将来的呼应时间和网络带宽耗费，同样也适用于请求音讯。"

由于WAP信道带宽的限制，我们在编写WAP使用的时候都希望最大限制地减少音讯的传送量。要做到这一点，就要尽量地使用缓存，经常地从缓存中获得以前的音讯。侥幸的是目前大多数WAP设备都有一定级别的缓存，在默认情况下，会尝试最大化的缓存。几乎所有指向URL的呼应都会被缓存下来。

当WAP用户终端缓存一个呼应的时候，会保存几乎所有的信息：URL、呼应文本、音讯头以及其他可以验证呼应的内容（参看下一节"验证和历史堆栈"）。每个被缓存的项目都可以依据它的URL组成部分（域名、路径、协议、参数、端口等等）独一的识别。

有两种HTTP音讯头可以让你控制WML的DECK缓存，对我们最重要的是Cache-Control音讯头。它能够直接通过请求/呼应链来控制所有的缓存实体。所有的缓存机制都必须恪守这些音讯头的定义。Cach-Control音讯头通常用来屏蔽一个设备的默认缓存行为。他们在音讯链中传递时必须直接穿过所有的代理服务器和网关而不被改变。

* Cache-Control: no-cache。设定这个选项的URL不能被缓存，包括用户终端和所有处于内容服务器和用户终端之间的其他服务器；
* Cache-Control: max-age=<second>。定义URL保存在设备缓存中的最长时间。时间到了当前，这个实体会从缓存中清除；
* Expired:<date> 。指定URL在缓存中存放的最后日期期限。[RFC1123]定义了日期的格式，通常是这样的：Expires: Sun,