HTTP远程变量选择算法—RVSA/1.0( 四 )


符类型,m是f和g的最大值 。这里是一些例子
text/html;q=1.0,text/plain;q=0.8-->text/*;q=1.0
image/*;q=0.8,application/*;q=0.7-->*/*;q=0.8
iso-8859-5;q=1.0,unicode-1-1;q=0.8-->*;q=1.0
注重上面的个‘;q=1.0’都是可选的,可以忽略:
iso-8859-7;q=0.6,*-->*
对于接收语言,可以安全地将所有具有相同主要标记符的语言域折叠为一个通配符:
en-us;q=0.9,en-gb;q=0.7,en;q=0.8,da-->*;q=0.9,da
也可以安全地将一个语言域折叠为一个通配符,或者将它替代为一个通配符,假如它的主要
标记符只出现一次:
*;q=0.9,da-->*
最后,在接收特征报头中,每一个特征表达式都能够被折叠为一个通配符,或者替代为一个
通配符:
colordepth!=5,*-->*
4.2.2忽略接收报头
根据HTTP/1.1说明[1],一个接收报头完全不存在于请求中等价于‘Accept:*/*’ 。因
此,假如接收报头被折叠成‘Accept:*/*’,用户代理可能完全忽略它 。包含‘*’的接收字
符集,接收语言,或接收特征也可能被忽略 。
4.2.3动态长度请求
一个能进行透明内容协商的用户代理也能缺省发送短请求 。一些短接收报头为了已存的
使用HTTP/1.0的服务器的利益,也能被包括进来(参见[2]的4.2节) 。这是一个例子:
GET/paperHTTP/1.1
Host:x.org
User-Agent:WuxtaWeb/2.4
Negotiate:1.0
Accept-Language:en,*;q=0.9
假如这样一个作为输入的缺省请求包含的接收报头和远程变量选择算法不匹配,用户代理就
能够发送‘Negotiate:trans’而不是‘Negotiate:1.0’,从而使算法失效 。
假如用户代理发现了,不管是否接收到一个列表或选择响应,一个非凡的源服务器包含透明
协商资源,它就能动态设置对这个服务器的以后的请求的长度,例如GET/paper/chapter1
HTTP/1.1
Host:x.org
User-Agent:WuxtaWeb/2.4
Negotiate:1.0
Accept:text/html,application/postscript;q=0.8,*/*
Accept-Language:en,fr;q=0.5,*;q=0.9
Accept-Features:tables,*
这将增加远程变量选择算法拥有足够信息为用户代理作出选择的机会,因而会使协商进程最
优化 。一个动态扩展的优良算法是用这些媒体类型,语言,字符集,和特征标记符来扩展报
头,这些都是在过去来自服务器的响应的变量列表中提到的 。
4.3本地和远程算法的区别
一个用户代理只能最优化内容协商,即使使用远程算法,而它的本地算法一般会做出相
同的选择 。假如用户代理收到一个包括由远程算法选择的变量X,而本地算法会选择Y,用
户代理有两种选择:
1. 在接下来的请求中重新得到Y 。这不是最佳方案,因为它费时间 。
2. 无论如何也要显示X 。这不是最佳方案,因为它使最终结果依靠于会随机改变的因数 。
对于对同一资源的下个请求,中间代理缓冲会返回一个列表响应,这会导致本地算法选
择并重新得到Y而不是X 。和稳定的表示相比,一个随机地在X和Y之间转换的表示的
品质低得多 。
因为上面的两种选择都没有吸引力,用户代理应该试着一起避免上面的两种情况 。下面
的几节讨论了这该如何实现 。
4.3避免主要区别
假如用户代理使这篇说明中的远程算法生效了,它应该按照惯例使用一个很类似远程算
法的本地算法 。此算法也应该使用乘法组合品质因数 。假如用户代理通过加法组合品质因数,
定义一个新远程变量选择算法会更有利,这个算法有一个新的主要版本号 。
4.3.2解决细微区别
即使一个本地算法使用乘法组合品质因数,它还是可以使用扩展的品质公式像:

推荐阅读