三、验证（validation）和历史堆栈（History Stack）
在HTTP1.1中对缓存进一步提出了验证的概念。验证的目的就是检验缓存项目是否在有效期内。由于历史堆栈的存在，WAP终端上的验证过程变得有点复杂。
WAP标准规定所有的WAP设备都至少要有可以容纳10-个项目的历史堆栈。当用户按下由<go>或其他转向指令的定义的前行（forward）链接时，URL被推（push）入堆栈。如果按下由<prev>定义的后退（backward）链接，URL被弹（pop）出。
一般情况下，所有的前行链接都会被验证，而后退链接则不会，因为它已经在cache里了。可是我们有时候还是希望当用户按下后退键时依然能够得到最新的数据。如果终端总是不予验证的话，那用户只好找到主菜单再重新进入那个页面。
幸运的是，我们用Cache-Control：must-revalidate就可以强迫用户终端在用户按back时对URL进行验证。当然，进行验证并不是说该页面会立刻重新读取，而是根据他是否过期来决定。如果没有过期，验证的结果仍然是显示缓存中的页面。
如果你需要每次back都重新读取页面，用Cache-Control：must-revalidate, no-cache可以实现。另外，把 no-cache换成max-age=300就可以在back时对已缓存了300秒的页面进行刷新。
四、HTTP头与meta元素
到这里，大家已经知道HTTP消息头的在WAP页面的作用了。不过要在WML文档里设置这些消息头，就要用到meta元素，它只能出现在WML文档<head>段里。下面是几个消息头和它们的表示形式：
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"/>
当网关在WML文档中扫描到元素时，就会把它们转换成WSP等效的HTTP消息头，然后用户终端就可以据此对缓存进行控制了。
上一页 [1] [2] [3] [4]
设为首页
加入收藏
联系我们
减小字体
增大字体