Network Working Group                                         K. Holtman
Request for Comments: 2296                                           TUE
Category: Experimental                                           A. Mutz
                                                         Hewlett-Packard
                                                              March 1998
        
Network Working Group                                         K. Holtman
Request for Comments: 2296                                           TUE
Category: Experimental                                           A. Mutz
                                                         Hewlett-Packard
                                                              March 1998
        

HTTP Remote Variant Selection Algorithm -- RVSA/1.0

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

Status of this Memo

本备忘录的状况

This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.

这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (1998). All Rights Reserved.

版权所有(C)互联网协会(1998年)。版权所有。

ABSTRACT

摘要

HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is a mechanism for automatically selecting the best version when the URL is accessed. A remote variant selection algorithm can be used to speed up the transparent negotiation process. This document defines the remote variant selection algorithm with the version number 1.0.

HTTP允许网站作者将同一信息的多个版本放在一个URL下。透明内容协商是一种机制,用于在访问URL时自动选择最佳版本。远程变量选择算法可用于加速透明协商过程。本文件定义了版本号为1.0的远程变量选择算法。

TABLE OF CONTENTS

目录

   1  Introduction...............................................2
   2  Terminology and notation...................................2
   3  The remote variant selection algorithm.....................2
    3.1 Input....................................................2
    3.2 Output...................................................3
    3.3 Computing overall quality values.........................3
    3.4 Definite and speculative quality values..................5
    3.5 Determining the result...................................6
   4  Use of the algorithm.......................................7
    4.1 Using quality factors to rank preferences................7
    4.2 Construction of short requests...........................8
    4.2.1 Collapsing Accept- header elements.....................8
    4.2.2 Omitting Accept- headers...............................9
    4.2.3 Dynamically lengthening requests.......................9
    4.3 Differences between the local and the remote algorithm..10
    4.3.1 Avoiding major differences............................11
    4.3.2 Working around minor differences......................11
        
   1  Introduction...............................................2
   2  Terminology and notation...................................2
   3  The remote variant selection algorithm.....................2
    3.1 Input....................................................2
    3.2 Output...................................................3
    3.3 Computing overall quality values.........................3
    3.4 Definite and speculative quality values..................5
    3.5 Determining the result...................................6
   4  Use of the algorithm.......................................7
    4.1 Using quality factors to rank preferences................7
    4.2 Construction of short requests...........................8
    4.2.1 Collapsing Accept- header elements.....................8
    4.2.2 Omitting Accept- headers...............................9
    4.2.3 Dynamically lengthening requests.......................9
    4.3 Differences between the local and the remote algorithm..10
    4.3.1 Avoiding major differences............................11
    4.3.2 Working around minor differences......................11
        
   5  Security and privacy considerations.......................11
   6  Acknowledgments...........................................12
   7  References................................................12
   8  Authors' Addresses........................................12
   9  Full Copyright Statement..................................13
        
   5  Security and privacy considerations.......................11
   6  Acknowledgments...........................................12
   7  References................................................12
   8  Authors' Addresses........................................12
   9  Full Copyright Statement..................................13
        

1 Introduction

1导言

HTTP allows web site authors to put multiple versions (variants) of the same information under a single URL. Transparent content negotiation [2] is a mechanism for automatically selecting the best variant when the URL is accessed. A remote variant selection algorithm can be used by a HTTP server to choose a best variant on behalf of a negotiating user agent. The use of a remote algorithm can speed up the transparent negotiation process by eliminating a request-response round trip.

HTTP允许网站作者在单个URL下放置相同信息的多个版本(变体)。透明内容协商[2]是一种机制,用于在访问URL时自动选择最佳变体。HTTP服务器可以使用远程变体选择算法代表协商用户代理选择最佳变体。使用远程算法可以通过消除请求-响应往返来加快透明协商过程。

This document defines the remote variant selection algorithm with the version number 1.0. The algorithm computes whether the Accept-headers in the request contain sufficient information to allow a choice, and if so, which variant must be chosen.

本文件定义了版本号为1.0的远程变量选择算法。该算法计算请求中的Accept头是否包含足够的信息以允许选择,如果是,则必须选择哪个变量。

2 Terminology and notation

2术语和符号

This specification uses the terminology and notation of the HTTP transparent content negotiation specification [2].

本规范使用HTTP透明内容协商规范[2]的术语和符号。

3 The remote variant selection algorithm

3.远程变量选择算法

This section defines the remote variant selection algorithm with the version number 1.0. To implement this definition, a server MAY run any algorithm which gives equal results.

本节定义了版本号为1.0的远程变量选择算法。为了实现这个定义,服务器可以运行任何给出相同结果的算法。

Note: According to [2], servers are always free to return a list response instead of running a remote algorithm. Therefore, whenever a server may run a remote algorithm, it may also run a partial implementation of the algorithm, provided that the partial implementation always returns List_response when it cannot compute the real result.

注意:根据[2],服务器总是可以自由返回列表响应,而不是运行远程算法。因此,每当服务器可以运行远程算法时,它也可以运行该算法的部分实现,前提是该部分实现在无法计算实际结果时总是返回List_响应。

3.1 Input
3.1 输入

The algorithm is always run for a particular request on a particular transparently negotiable resource. It takes the following information as input.

该算法总是针对特定透明可协商资源上的特定请求运行。它将以下信息作为输入。

1. The variant list of the resource, as present in the Alternates header of the resource.

1. 资源的变体列表,如资源的Alternates标头中所示。

2. (Partial) Information about capabilities and preferences of the user agent for this particular request, as given in the Accept-headers of the request.

2. (部分)有关此特定请求的用户代理的功能和首选项的信息,如请求的Accept标头中所示。

If a fallback variant description

如果需要回退变量说明

{"fallback.html"}

{“fallback.html”}

is present in the Alternates header, the algorithm MUST interpret it as the variant description

如果存在于Alternates标头中,则算法必须将其解释为变量描述

{"fallback.html" 0.000001}

{“fallback.html”0.000001}

The extremely low source quality value ensures that the fallback variant only gets chosen if all other options are exhausted.

极低的源质量值确保只有在用尽所有其他选项的情况下才选择回退变量。

3.2 Output
3.2 输出

As its output, the remote variant selection algorithm and will yield the appropriate action to be performed. There are two possibilities:

作为其输出,远程变量选择算法和将产生要执行的适当操作。有两种可能性:

Choice_response

选择与回应

The Accept- headers contain sufficient information to make a choice on behalf of the user agent possible, and the best variant MAY be returned in a choice response.

Accept-Header包含足够的信息,可以代表用户代理进行选择,并且可以在选择响应中返回最佳变量。

List_response

列出您的答复

The Accept- headers do not contain sufficient information to make a choice on behalf of the user agent possible. A list response MUST be returned, allowing the user agent to make the choice itself.

Accept-Header包含的信息不足,无法代表用户代理进行选择。必须返回一个列表响应,允许用户代理自己进行选择。

3.3 Computing overall quality values
3.3 计算总体质量值

As a first step in the remote variant selection algorithm, the overall qualities of the individual variants in the list are computed.

作为远程变量选择算法的第一步,将计算列表中各个变量的总体质量。

The overall quality Q of a variant is the value

变量的总体质量Q是值

      Q = round5( qs * qt * qc * ql * qf )
        
      Q = round5( qs * qt * qc * ql * qf )
        

where round5 is a function which rounds a floating point value to 5 decimal places after the point, and where the factors qs, qt, qc, ql, and qf are determined as follows.

其中round5是一个函数,它将浮点值舍入到小数点后5位,其中因子qs、qt、qc、ql和qf的确定如下。

qs Is the source quality factor in the variant description.

qs是变量描述中的源质量因子。

qt The media type quality factor is 1 if there is no type attribute in the variant description, or if there is no Accept header in the request. Otherwise, it is the quality assigned by the Accept header to the media type in the type attribute.

qt如果变量描述中没有type属性,或者请求中没有Accept头,则媒体类型质量因子为1。否则,它是由接受标头在类型属性中指定给媒体类型的质量。

Note: If a type is matched by none of the elements of an Accept header, the Accept header assigns the quality factor 0 to that type.

注意:如果某个类型与接受标头的任何元素都不匹配,则接受标头会将质量因子0指定给该类型。

qc The charset quality factor is 1 if there is no charset attribute in the variant description, or if there is no Accept-Charset header in the request. Otherwise, the charset quality factor is the quality assigned by the Accept-Charset header to the charset in the charset attribute.

qc如果变量描述中没有字符集属性,或者请求中没有Accept字符集标头,则字符集质量因子为1。否则,字符集质量因子是由Accept字符集标头分配给charset属性中的字符集的质量。

ql The language quality factor is 1 if there is no language attribute in the variant description, or if there is no Accept-Language header in the request. Otherwise, the language quality factor is the highest quality factor assigned by the Accept-Language header to any one of the languages listed in the language attribute.

ql如果变量描述中没有language属性,或者请求中没有Accept language标头,则语言质量因子为1。否则,language quality factor是Accept language标头指定给language属性中列出的任何一种语言的最高质量因子。

qf The features quality factor is 1 if there is no features attribute in the variant description, or if there is no Accept-Features header in the request. Otherwise, it is the quality degradation factor for the features attribute, see section 6.4 of [2].

qf如果变量描述中没有features属性,或者请求中没有Accept features标头,则features质量因子为1。否则,它是“特征”属性的质量降级因子,请参见[2]的第6.4节。

As an example, if a variant list contains the variant description

例如,如果变量列表包含变量描述

     {"paper.html.en" 0.7 {type text/html} {language fr}}
        
     {"paper.html.en" 0.7 {type text/html} {language fr}}
        

and if the request contains the Accept- headers

如果请求包含Accept-header

     Accept: text/html:q=1.0, */*:q=0.8
     Accept-Language: en;q=1.0, fr;q=0.5
        
     Accept: text/html:q=1.0, */*:q=0.8
     Accept-Language: en;q=1.0, fr;q=0.5
        

the remote variant selection algorithm will compute an overall quality for the variant as follows:

远程变量选择算法将计算变量的总体质量,如下所示:

     {"paper.html.fr" 0.7 {type text/html} {language fr}}
                       |           |                 |
                       |           |                 |
                       V           V                 V
             round5 ( 0.7   *     1.0        *      0.5 ) = 0.35000
        
     {"paper.html.fr" 0.7 {type text/html} {language fr}}
                       |           |                 |
                       |           |                 |
                       V           V                 V
             round5 ( 0.7   *     1.0        *      0.5 ) = 0.35000
        

With the above Accept- headers, the complete variant list

通过上面的Accept-Header,完整的变量列表

     {"paper.html.en" 0.9 {type text/html} {language en}},
     {"paper.html.fr" 0.7 {type text/html} {language fr}},
     {"paper.ps.en"   1.0 {type application/postscript} {language en}}
        
     {"paper.html.en" 0.9 {type text/html} {language en}},
     {"paper.html.fr" 0.7 {type text/html} {language fr}},
     {"paper.ps.en"   1.0 {type application/postscript} {language en}}
        

would yield the following computations:

将产生以下计算结果:

            round5 ( qs  * qt  * qc  * ql  * qf  ) =   Q
                     ---   ---   ---   ---   ---     -------
      paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0   = 0.90000
      paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0   = 0.35000
      paper.ps.en:   1.0 * 0.8 * 1.0 * 1.0 * 1.0   = 0.80000
        
            round5 ( qs  * qt  * qc  * ql  * qf  ) =   Q
                     ---   ---   ---   ---   ---     -------
      paper.html.en: 0.9 * 1.0 * 1.0 * 1.0 * 1.0   = 0.90000
      paper.html.fr: 0.7 * 1.0 * 1.0 * 0.5 * 1.0   = 0.35000
      paper.ps.en:   1.0 * 0.8 * 1.0 * 1.0 * 1.0   = 0.80000
        
3.4 Definite and speculative quality values
3.4 确定和推测的质量值

A computed overall quality value can be either definite or speculative. An overall quality value is definite if it was computed without using any wildcard characters '*' in the Accept- headers, and without the need to use the absence of a particular Accept- header. An overall quality value is speculative otherwise.

计算出的总体质量值可以是确定的,也可以是推测的。如果计算的总体质量值在Accept-header中不使用任何通配符“*”,并且不需要使用缺少特定Accept-header,则该值是确定的。否则,总体质量值是推测性的。

As an example, in the previous section, the quality values of paper.html.en and paper.html.fr are definite, and the quality value of paper.ps.en is speculative because the type application/postscript was matched to the range */*.

例如,在上一节中,paper.html.en和paper.html.fr的质量值是确定的,paper.ps.en的质量值是推测性的,因为类型application/postscript与范围*/*匹配。

Definiteness can be defined more formally as follows. An overall quality value Q is definite if the same quality value Q can be computed after the request message is changed in the following way:

确定性可以更正式地定义如下。如果在请求消息以以下方式更改后可以计算相同的质量值Q,则总体质量值Q是确定的:

1. If an Accept, Accept-Charset, Accept-Language, or Accept-Features header is missing from the request, add this header with an empty field.

1. 如果请求中缺少Accept、Accept字符集、Accept Language或Accept Features标头,请使用空字段添加此标头。

2. Delete any media ranges containing a wildcard character '*' from the Accept header. Delete any wildcard '*' from the Accept-Charset, Accept-Language, and Accept-Features headers.

2. 从Accept标头中删除包含通配符“*”的任何媒体范围。从Accept字符集、Accept Language和Accept Features标头中删除任何通配符“*”。

As another example, the overall quality factor for the variant

另一个例子是,变量的总体质量系数

     {"blah.html" 1 {language en-gb} {features blebber [x y]}}
        
     {"blah.html" 1 {language en-gb} {features blebber [x y]}}
        

is 1 and definite with the Accept- headers

是1,并与Accept-header一起确定

     Accept-Language: en-gb, fr
     Accept-Features: blebber, x, !y, *
        
     Accept-Language: en-gb, fr
     Accept-Features: blebber, x, !y, *
        

and

Accept-Language: en, fr Accept-Features: blebber, x, *

接受语言:en,fr接受特征:blebber,x*

The overall quality factor is still 1, but speculative, with the Accept- headers

总的质量因子仍然是1,但是是推测性的,带有Accept-header

     Accept-language: en-gb, fr
     Accept-Features: blebber, !y, *
        
     Accept-language: en-gb, fr
     Accept-Features: blebber, !y, *
        

and

     Accept-Language: fr, *
     Accept-Features: blebber, x, !y, *
        
     Accept-Language: fr, *
     Accept-Features: blebber, x, !y, *
        
3.5 Determining the result
3.5 确定结果

The best variant, as determined by the remote variant selection algorithm, is the one variant with the highest overall quality value, or, if there are multiple variants which share the highest overall quality, the first variant in the list with this value.

远程变量选择算法确定的最佳变量是具有最高总体质量值的一个变量,或者,如果有多个变量共享最高总体质量,则列表中具有该值的第一个变量。

The end result of the remote variant selection algorithm is Choice_response if all of the following conditions are met

如果满足以下所有条件,远程变量选择算法的最终结果是Choice_响应

a. the overall quality value of the best variant is greater than 0

a. 最佳变体的总体质量值大于0

b. the overall quality value of the best variant is a definite quality value

b. 最佳变体的总体质量值是一个确定的质量值

c. the variant resource is a neighbor of the negotiable resource. This last condition exists to ensure that a security-related restriction on the generation of choice responses is met, see sections 10.2 and 14.2 of [2].

c. 变体资源是可协商资源的邻居。最后一个条件的存在是为了确保满足对选择响应生成的安全相关限制,请参见[2]第10.2节和第14.2节。

In all other cases, the end result is List_response.

在所有其他情况下,最终结果是List_响应。

The requirement for definiteness above affects the interpretation of Accept- headers in a dramatic way. For example, it causes the remote algorithm to interpret the header

上面对明确性的要求以一种戏剧性的方式影响了Accept-header的解释。例如,它使远程算法解释报头

     Accept: image/gif;q=0.9, */*;q=1.0
        
     Accept: image/gif;q=0.9, */*;q=1.0
        

as

`I accept image/gif with a quality of 0.9, and assign quality

`我接受质量为0.9的image/gif,并指定质量

factors up to 1.0 to other media types. If this information is insufficient to make a choice on my behalf, do not make a choice but send the list of variants'.

将系数高达1.0的其他媒体类型。如果此信息不足以代表我做出选择,请不要做出选择,而是发送变体列表”。

Without the requirement, the interpretation would have been

如果没有这一要求,解释将是错误的

`I accept image/gif with a quality of 0.9, and all other media types with a quality of 1.0'.

`我接受质量为0.9的image/gif,以及质量为1.0'的所有其他媒体类型。

4 Use of the algorithm

4算法的使用

This section discusses how user agents can use the remote algorithm in an optimal way. This section is not normative, it is included for informational purposes only.

本节讨论用户代理如何以最佳方式使用远程算法。本节不规范,仅供参考。

4.1 Using quality factors to rank preferences
4.1 使用质量因素对偏好进行排序

Using quality factors, a user agent can not only rank the elements within a particular Accept- header, it can also express precedence relations between the different Accept- headers. Consider for example the following variant list:

使用质量因子,用户代理不仅可以对特定接受头中的元素进行排序,还可以表示不同接受头之间的优先级关系。例如,考虑以下变量列表:

     {"paper.english" 1.0 {language en} {charset ISO-8859-1}},
     {"paper.greek"   1.0 {language el} {charset ISO-8859-7}}
        
     {"paper.english" 1.0 {language en} {charset ISO-8859-1}},
     {"paper.greek"   1.0 {language el} {charset ISO-8859-7}}
        

and suppose that the user prefers "el" over "en", while the user agent can render "ISO-8859-1" with a higher quality than "ISO-8859- 7". If the Accept- headers are

假设用户更喜欢“el”而不是“en”,而用户代理可以以比“ISO-8859-7”更高的质量呈现“ISO-8859-1”。如果Accept-header是

     Accept-Language: gr, en;q=0.8
     Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, *
        
     Accept-Language: gr, en;q=0.8
     Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.6, *
        

then the remote variant selection algorithm would choose the English variant, because this variant has the least overall quality degradation. But if the Accept- headers are

然后,远程变体选择算法将选择英语变体,因为该变体的总体质量下降最少。但是如果Accept-header是

     Accept-Language: gr, en;q=0.8
     Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, *
        
     Accept-Language: gr, en;q=0.8
     Accept-Charset: ISO-8859-1, ISO-8859-7;q=0.95, *
        

then the algorithm would choose the Greek variant. In general, the Accept- header with the biggest spread between its quality factors gets the highest precedence. If a user agent allows the user to set the quality factors for some headers, while other factors are hard-coded, it should use a low spread on the hard-coded factors and a high spread on the user-supplied factors, so that the user settings take precedence over the built-in settings.

然后算法将选择希腊变体。一般来说,质量因子之间的差异最大的Accept-header具有最高的优先级。如果用户代理允许用户设置某些标题的质量因子,而其他因子是硬编码的,则应在硬编码因子上使用低排列,在用户提供的因子上使用高排列,以便用户设置优先于内置设置。

4.2 Construction of short requests
4.2 短请求的构造

In a request on a transparently negotiated resource, a user agent need not send a very long Accept- header, which lists all of its capabilities, to get optimal results. For example, instead of sending

在对透明协商资源的请求中,用户代理不需要发送很长的Accept-header(列出其所有功能)来获得最佳结果。例如,不发送

     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, 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
        

the user agent can send

用户代理可以发送

     Accept: image/gif;q=0.9, */*;q=1.0
        
     Accept: image/gif;q=0.9, */*;q=1.0
        

It can send this short header without running the risk of getting a choice response with, say, an inferior image/tiff variant. For example, with the variant list

它可以发送此短标题,而不必冒获得选择响应的风险,例如,使用劣质图像/tiff变体。例如,使用变量列表

{"x.gif" 1.0 {type image/gif}}, {"x.tiff" 1.0 {type image/tiff}},

{“x.gif”1.0{type image/gif},{“x.tiff”1.0{type image/tiff},

the remote algorithm will compute a definite overall quality of 0.9 for x.gif and a speculative overall quality value of 1.0 for x.tiff. As the best variant has a speculative quality value, the algorithm will not choose x.tiff, but return a list response, after which the selection algorithm of the user agent will correctly choose x.gif. The end result is the same as if the long Accept- header above had been sent.

远程算法将计算x.gif的确定总体质量为0.9,x.tiff的推测总体质量值为1.0。由于最佳变体具有推测性质量值,因此算法不会选择x.tiff,而是返回一个列表响应,之后用户代理的选择算法将正确选择x.gif。最终结果与上面的长Accept-header发送时的结果相同。

Thus, user agents can vary the length of the Accept- headers to get an optimal tradeoff between the speed with which the first request is transmitted, and the chance that the remote algorithm has enough information to eliminate a second request.

因此,用户代理可以改变接受头的长度,以在第一个请求的传输速度和远程算法有足够信息消除第二个请求的可能性之间获得最佳折衷。

4.2.1 Collapsing Accept- header elements
4.2.1 折叠Accept-header元素

This section discusses how a long Accept- header which lists all capabilities and preferences can be safely made shorter. The remote variant selection algorithm is designed in such a way that it is always safe to shorten an Accept or Accept-Charset header by two taking two header elements `A;q=f' and `B;q=g' and replacing them by a single element `P;q=m' where P is a wildcard pattern that matches both A and B, and m is the maximum of f and g. Some examples are

本节讨论如何安全地缩短列出所有功能和首选项的长Accept-header。远程变量选择算法的设计方式是,将一个Accept或Accept字符集报头缩短两个,取两个报头元素`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
        
      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
        
      iso-8859-5;q=1.0, unicode-1-1;q=0.8     -->    *;q=1.0
        

Note that every `;q=1.0' above is optional, and can be omitted:

注意每个`;以上q=1.0'是可选的,可以省略:

      iso-8859-7;q=0.6, *                     -->    *
        
      iso-8859-7;q=0.6, *                     -->    *
        

For Accept-Language, it is safe to collapse all language ranges with the same primary tag into a wildcard:

对于Accept Language,可以安全地将具有相同主标记的所有语言范围折叠为通配符:

      en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da  -->    *;q=0.9, da
        
      en-us;q=0.9, en-gb;q=0.7, en;q=0.8, da  -->    *;q=0.9, da
        

It is also safe to collapse a language range into a wildcard, or to replace it by a wildcard, if its primary tag appears only once:

如果一个语言范围的主标记只出现一次,则将其折叠为通配符或用通配符替换也是安全的:

      *;q=0.9, da                             -->    *
        
      *;q=0.9, da                             -->    *
        

Finally, in the Accept-Features header, every feature expression can be collapsed into a wildcard, or replaced by a wildcard:

最后,在Accept Features标头中,可以将每个要素表达式折叠为通配符,或替换为通配符:

      colordepth!=5, *                        -->    *
        
      colordepth!=5, *                        -->    *
        
4.2.2 Omitting Accept- headers
4.2.2 省略Accept-header

According to the HTTP/1.1 specification [1], the complete absence of an Accept header from the request is equivalent to the presence of `Accept: */*'. Thus, if the Accept header is collapsed to `Accept: */*', a user agent may omit it entirely. An Accept-Charset, Accept-Language, or Accept-Features header which only contains `*' may also be omitted.

根据HTTP/1.1规范[1],请求中完全没有Accept头相当于存在“Accept://*”。因此,如果Accept标头折叠为“Accept://*”,则用户代理可能会完全忽略它。也可以省略仅包含“*”的Accept字符集、Accept语言或Accept Features标头。

4.2.3 Dynamically lengthening requests
4.2.3 动态延长请求

In general, a user agent capable of transparent content negotiation can send short requests by default. Some short Accept- headers could be included for the benefit of existing servers which use HTTP/1.0 style negotiation (see section 4.2 of [2]). An example is

通常,默认情况下,能够进行透明内容协商的用户代理可以发送短请求。为了使使用HTTP/1.0风格协商的现有服务器受益,可以包含一些简短的Accept-Header(参见[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
        
      GET /paper HTTP/1.1
      Host: x.org
      User-Agent: WuxtaWeb/2.4
      Negotiate: 1.0
      Accept-Language: en, *;q=0.9
        

If the Accept- headers included in such a default request are not suitable as input to the remote variant selection algorithm, the user agent can disable the algorithm by sending `Negotiate: trans' instead of `Negotiate: 1.0'.

如果默认请求中包含的Accept-Header不适合作为远程变量选择算法的输入,则用户代理可以通过发送“协商:trans”而不是“协商:1.0”来禁用该算法。

If the user agent discovers, though the receipt of a list or choice response, that a particular origin server contains transparently negotiated resources, it could dynamically lengthen future requests to this server, for example to

如果用户代理通过接收列表或选择响应发现特定的源服务器包含透明协商的资源,则它可以动态地延长将来对此服务器的请求,例如

      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, *
        
      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, *
        

This will increase the chance that the remote variant selection algorithm will have sufficient information to choose on behalf of the user agent, thereby optimizing the negotiation process. A good strategy for dynamic extension would be to extend the headers with those media types, languages, charsets, and feature tags mentioned in the variant lists of past responses from the server.

这将增加远程变量选择算法具有代表用户代理选择的足够信息的机会,从而优化协商过程。动态扩展的一个好策略是使用服务器过去响应的变体列表中提到的媒体类型、语言、字符集和功能标签扩展头。

4.3 Differences between the local and the remote algorithm
4.3 本地和远程算法之间的差异

A user agent can only optimize content negotiation though the use of a remote algorithm if its local algorithm will generally make the same choice. If a user agent receives a choice response containing a variant X selected by the remote algorithm, while the local algorithm would have selected Y, the user agent has two options:

如果用户代理的本地算法通常会做出相同的选择,则用户代理只能通过使用远程算法来优化内容协商。如果用户代理收到包含远程算法选择的变量X的选择响应,而本地算法将选择Y,则用户代理有两个选项:

1. Retrieve Y in a subsequent request. This is sub-optimal because it takes time.

1. 在后续请求中检索Y。这是次优的,因为它需要时间。

2. Display X anyway. This is sub-optimal because it makes the end result of the negotiation process dependent on factors that can randomly change. For the next request on the same resource, and intermediate proxy cache could return a list response, which would cause the local algorithm to choose and retrieve Y instead of X. Compared to a stable representation, a representation which randomly switches between X and Y (say, the version with and without frames) has a very low subjective quality for most users.

2. 还是显示X。这是次优的,因为它使谈判过程的最终结果取决于可能随机变化的因素。对于同一资源上的下一个请求,中间代理缓存可能会返回列表响应,这将导致本地算法选择并检索Y而不是X。与稳定表示法相比,该表示法在X和Y之间随机切换(例如,有帧和无帧的版本)对于大多数用户来说,它的主观质量很低。

As both alternatives above are unattractive, a user agent should try to avoid the above situation altogether. The sections below discuss how this can be done.

由于上述两种备选方案都不具吸引力,用户代理应该尝试完全避免上述情况。以下各节讨论如何做到这一点。

4.3.1 Avoiding major differences
4.3.1 避免重大分歧

If the user agent enables the remote algorithm in this specification, it should generally use a local algorithm which closely resembles the remote algorithm. The algorithm should for example also use multiplication to combine quality factors. If the user agent combines quality factors by addition, it would be more advantageous to define a new remote variant selection algorithm, with a new major version number, for use by this agent.

如果用户代理启用本规范中的远程算法,则通常应使用与远程算法非常相似的本地算法。例如,算法还应该使用乘法来组合质量因子。如果用户代理通过添加将质量因素结合起来,则更有利的做法是定义一个新的远程变量选择算法,以及一个新的主要版本号,供该代理使用。

4.3.2 Working around minor differences
4.3.2 围绕细微差异开展工作

Even if a local algorithm uses multiplication to combine quality factors, it could use an extended quality formulae like

即使局部算法使用乘法组合质量因子,也可以使用扩展的质量公式,如

      Q = round5( qs * qt * qc * ql * qf ) * q_adjust
        
      Q = round5( qs * qt * qc * ql * qf ) * q_adjust
        

in order to account for special interdependencies between dimensions, which are due to limitations of the user agent. For example, if the user agent, for some reason, cannot handle the iso-8859-7 charset when rendering text/plain documents, the q_adjust factor would be 0 when the text/plain - iso-8859-7 combination is present in the variant description, and 1 otherwise.

为了解释由于用户代理的限制而导致的维度之间的特殊相互依赖关系。例如,如果由于某种原因,用户代理在呈现文本/普通文档时无法处理iso-8859-7字符集,则当文本/普通-iso-8859-7组合出现在变体描述中时,q_调整因子将为0,否则为1。

By selectively withholding information from the remote variant selection algorithm, the user agent can ensure that the remote algorithm will never make a choice if the local q_adjust is less than 1. For example, to prevent the remote algorithm from ever returning a text/plain - iso-8859-7 choice response, the user agent should take care to never produce a request which exactly specifies the quality factors of both text/plain and iso-8859-7. The omission of either factor from a request will cause the overall quality value of any text/plain - iso-8859-7 variant to be speculative, and variants with speculative quality values can never be returned in a choice response.

通过选择性地保留来自远程变量选择算法的信息,用户代理可以确保如果本地q_adjust小于1,远程算法将永远不会做出选择。例如,为了防止远程算法返回text/plain-iso-8859-7选择响应,用户代理应该注意不要生成一个请求,该请求准确地指定text/plain和iso-8859-7的质量因子。请求中省略任一因素都会导致任何文本/纯文本-iso-8859-7变体的总体质量值具有推测性,并且具有推测性质量值的变体永远无法在选择响应中返回。

In general, if the local q_adjust does not equal 1 for a particular combination X - Y - Z, then a remote choice can be prevented by always omitting at least one of the elements of the combination from the Accept- headers, and adding a suitable wildcard pattern to match the omitted element, if such a pattern is not already present.

通常,如果对于特定组合X-Y-Z,本地q_adjust不等于1,则可以通过始终从接受头中省略组合的至少一个元素,并添加合适的通配符模式以匹配省略的元素(如果该模式尚未存在)来防止远程选择。

5 Security and privacy considerations

5安全和隐私注意事项

This specification introduces no security and privacy considerations not already covered in [2]. See [2] for a discussion of privacy risks connected to the sending of Accept- headers.

本规范未引入[2]中未涉及的安全和隐私注意事项。有关发送Accept-Header的隐私风险的讨论,请参见[2]。

6 Acknowledgments

6致谢

Work on HTTP content negotiation has been done since at least 1993. The authors are unable to trace the origin of many of the ideas incorporated in this document. Many members of the HTTP working group have contributed to the negotiation model in this specification. The authors wish to thank the individuals who have commented on earlier versions of this document, including Brian Behlendorf, Daniel DuBois, Ted Hardie, Larry Masinter, and Roy T. Fielding.

HTTP内容协商的工作至少从1993年就开始了。作者无法追溯本文件中包含的许多想法的起源。HTTP工作组的许多成员对本规范中的协商模型做出了贡献。作者希望感谢对本文件早期版本发表评论的个人,包括Brian Behlendorf、Daniel DuBois、Ted Hardie、Larry Masinter和Roy T.Fielding。

7 References

7参考文献

[1] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.

[1] 菲尔丁,R.,盖蒂斯,J.,莫卧儿,J.,弗莱斯蒂克,H.,和T.伯纳斯李,“超文本传输协议——HTTP/1.1”,RFC 2068,1997年1月。

[2] Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998.

[2] Holtman,K.和A.Mutz,“HTTP中的透明内容协商”,RFC 2295,1998年3月。

8 Authors' Addresses

8作者地址

Koen Holtman Technische Universiteit Eindhoven Postbus 513 Kamer HG 6.57 5600 MB Eindhoven (The Netherlands)

科恩·霍特曼埃因霍温技术大学邮政513卡默HG 6.57 5600 MB埃因霍温(荷兰)

   EMail: koen@win.tue.nl
        
   EMail: koen@win.tue.nl
        

Andrew H. Mutz Hewlett-Packard Company 1501 Page Mill Road 3U-3 Palo Alto CA 94304, USA

美国加利福尼亚州帕洛阿尔托市佩奇米尔路3号U-3号1501号安德鲁·H·穆茨惠普公司,邮编94304

   Fax:   +1 415 857 4691
   EMail: mutz@hpl.hp.com
        
   Fax:   +1 415 857 4691
   EMail: mutz@hpl.hp.com
        

9 Full Copyright Statement

9完整版权声明

Copyright (C) The Internet Society (1998). All Rights Reserved.

版权所有(C)互联网协会(1998年)。版权所有。

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.

本文件和其中包含的信息是按“原样”提供的,互联网协会和互联网工程任务组否认所有明示或暗示的保证,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。