rfc2296.txt

很多RFC的中文文档

   使用品质因数，用户代理不仅可以为一个特别接收报头里的元素划分等级，而且也能表
示不同接收报头之间的优先等级。比如考虑下面的变量列表：
{"paper.english" 1.0 {language en} {charset ISO-8859-1}},
{"paper.greek"   1.0 {language el} {charset ISO-8859-7}}
并且假设用户选择“el”而不是“en”，这时用户代理能使“ISO-8859-1”的品质比“ISO-8859-7”
的高。如果接收报头是：
Accept-Language: gr, en；q=0.8
Accept-Charset: ISO-8859-1, ISO-8859-7；q=0.6, *
那么远程变量选择算法会选择English变量，因为这个变量的总体品质退化最少。但是如果
接收报头是
Accept-Language: gr, en;q=0.8
Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, *
那么算法就会选择Greek变量。一般地,品质因数之间差额最大的接收报头获得最高优先权。
如果用户代理允许用户为一些报头设置品质因数，同时其它因数都是hard-coded的，它就
应该对hard-coded的因数使用一个低差额，对用户提供的因数提供一个高差额，所以用户
设置比内置设置具有更高的优先权。
4.2短请求的构造
   在对透明可协商资源的一个请求中，用户代理不需要发送一个列出所有功能的长接收报
头。比如，不发送
Accept: image/gif;q=0.9, image/jpeg;q=0.8, image/png;q=1.0,

             image/tiff;q=0.5, image/ief;q=0.5, image/x-xbitmap;q=0.8,
             application/plugin1;q=1.0, application/plugin2;q=0.9
用户代理发送
Accept: image/gif;q=0.9, */*;q=1.0
它能发送短报头，从而不冒获得一个次等image/tiff变量的选择响应的危险。例如，对变
量列表
{"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}},
远程算法将为x.gif计算一个确定的总体品质0.9，并为x.tiff计算一个不确定的总体品
质因值1.0。因为最优变量拥有一个不确定的品质值，算法不会选择x.tiff，而是返回一个
列表响应，在此之后用户代理的选择算法会正确地选择x.gif。最终结果和发送长接收报头
得到的结果相同。
因此，用户能改变接收报头的长度以在首次请求发送速度，和远程算法拥有足够信息消除第
二次请求的机会之间获得最佳平衡。
4.2.1折叠接收报头元素
   这节讨论一个列出所有功能和参数的长接收报头如何被安全地缩短。远程变量算法按某
种方式设计，使得它总可以这安全地缩短接收或接收字符集报头，它提取两个报头元素
‘A;q=f’和‘B;q=g’并用一个元素‘P;q=m’代替它们，这里P是一个匹配A和B的通配
符类型，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 /paper HTTP/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解决细微区别
即使一个本地算法使用乘法组合品质因数，它还是可以使用扩展的品质公式像：
Q = round5( qs * qt * qc * ql * qf ) * q_adjust
以解决维之间的特殊相互依赖，这种依赖源自用户代理的局限性。例如，如果用户代理，由
于某种原因，在翻译text/plain文档时不能处理iso-8859-7字符集，而text/plain - 
iso-8859-7组合在变量描述中出现时，q_adjuster因数就会为0，否则为1。
通过选择性地扣留来自远程变量选择算法的信息，用户代理能确保如果本地q_adjust
小于1，远程算法永远不会作出一个选择。例如，为阻止远程算法返回一个text/plain - 
iso-8859-7选择响应，用户代理应该小心永远不要产生一个精确说明text/plain和
iso-8859-7品质因数的请求。对一个请求的任一因数的忽略都会任何text/plain - 
iso-8859-7变量的总体品质值成为不确定的，拥有不确定品质值的变量永远不会在一个选
择响应中返回。
一般地，对一个特殊的组合X-Y-X，如果本地q_adjust不等于1，一个远程选择可以
通过如下方式阻止，总是忽略来自接收报头的组合中的元素，并加上一个合适的通配符类型
来匹配忽略的元素，如果这样的类型还没有存在的话。
5．0安全和隐私考虑
这部分说明没有介绍任何［2］中还没有涉及到的安全和隐私考虑。参见［2］以获得和
接收报头相关的隐私风险。
6．致谢
有关HTTP内容协商的工作至少自1993年就已经做好了。作者不能够追溯这篇文档中的
许多观点的来源。许多HTTP工作组的成员对这篇说明中的协商模型作出了贡献。作者衷心
感谢那些对这篇文档早期版本作出评论的个人，包括Brian Behlendorf, Daniel DuBois, 
Ted Hardie, Larry Masinter, and Roy T.Fielding.
7．参考文献
   [1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and
       T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
       2068, January 1997.
   [2] Holtman, K., and A. Mutz, "Transparent Content Negotiation in
       HTTP", RFC 2295, March 1998.
8．作者地址
   Koen Holtman
   Technische Universiteit Eindhoven
   Postbus 513
   Kamer HG 6.57
   5600 MB Eindhoven (The Netherlands)
   EMail: [e-mail]
   
Andrew H. Mutz
   Hewlett-Packard Company
   1501 Page Mill Road 3U-3
   Palo Alto CA 94304, USA
   Fax:   [phone]
   EMail: [e-mail]
9．完整版权说明
   Copyright (C) The Internet Society (1998).  All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.
   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
RFC2296——HTTP Remote Variant Selection Algorithm -- RVSA/1.0   HTTP远程变量选择算法—RVSA/1.0


1
RFC文档中文翻译计划