Network Working Group K. Holtman
Request for Comments: 2295 TUE
Category: Experimental A. Mutz
Hewlett-Packard
March 1998
Network Working Group K. Holtman
Request for Comments: 2295 TUE
Category: Experimental A. Mutz
Hewlett-Packard
March 1998
Transparent Content Negotiation in HTTP
HTTP中的透明内容协商
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 an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.
HTTP允许网站作者将同一信息的多个版本放在一个URL下。透明内容协商是一种可扩展的协商机制，分层在HTTP之上，用于在访问URL时自动选择最佳版本。这使得能够顺利部署新的web数据格式和标记标记。
TABLE OF CONTENTS
目录
1 Introduction................................................4
1.1 Background................................................4
1 Introduction................................................4
1.1 Background................................................4
2 Terminology.................................................5
2.1 Terms from HTTP/1.1.......................................5
2.2 New terms.................................................6
2 Terminology.................................................5
2.1 Terms from HTTP/1.1.......................................5
2.2 New terms.................................................6
3 Notation....................................................8
3 Notation....................................................8
4 Overview....................................................9
4.1 Content negotiation.......................................9
4.2 HTTP/1.0 style negotiation scheme.........................9
4.3 Transparent content negotiation scheme...................10
4.4 Optimizing the negotiation process.......................12
4.5 Downwards compatibility with non-negotiating user agents.14
4.6 Retrieving a variant by hand.............................15
4.7 Dimensions of negotiation................................15
4 Overview....................................................9
4.1 Content negotiation.......................................9
4.2 HTTP/1.0 style negotiation scheme.........................9
4.3 Transparent content negotiation scheme...................10
4.4 Optimizing the negotiation process.......................12
4.5 Downwards compatibility with non-negotiating user agents.14
4.6 Retrieving a variant by hand.............................15
4.7 Dimensions of negotiation................................15
4.8 Feature negotiation......................................15
4.9 Length of variant lists..................................16
4.10 Relation with other negotiation schemes.................16
4.8 Feature negotiation......................................15
4.9 Length of variant lists..................................16
4.10 Relation with other negotiation schemes.................16
5 Variant descriptions.......................................17
5.1 Syntax...................................................17
5.2 URI......................................................17
5.3 Source-quality...........................................18
5.4 Type, charset, language, and length......................19
5.5 Features.................................................19
5.6 Description..............................................19
5.7 Extension-attribute......................................20
5 Variant descriptions.......................................17
5.1 Syntax...................................................17
5.2 URI......................................................17
5.3 Source-quality...........................................18
5.4 Type, charset, language, and length......................19
5.5 Features.................................................19
5.6 Description..............................................19
5.7 Extension-attribute......................................20
6 Feature negotiation........................................20
6.1 Feature tags.............................................20
6.1.1 Feature tag values.....................................21
6.2 Feature sets.............................................21
6.3 Feature predicates.......................................22
6.4 Features attribute.......................................24
6 Feature negotiation........................................20
6.1 Feature tags.............................................20
6.1.1 Feature tag values.....................................21
6.2 Feature sets.............................................21
6.3 Feature predicates.......................................22
6.4 Features attribute.......................................24
7 Remote variant selection algorithms........................25
7.1 Version numbers..........................................25
7 Remote variant selection algorithms........................25
7.1 Version numbers..........................................25
8 Content negotiation status codes and headers...............25
8.1 506 Variant Also Negotiates..............................25
8.2 Accept-Features..........................................26
8.3 Alternates...............................................27
8.4 Negotiate................................................28
8.5 TCN......................................................30
8.6 Variant-Vary.............................................30
8 Content negotiation status codes and headers...............25
8.1 506 Variant Also Negotiates..............................25
8.2 Accept-Features..........................................26
8.3 Alternates...............................................27
8.4 Negotiate................................................28
8.5 TCN......................................................30
8.6 Variant-Vary.............................................30
9 Cache validators...........................................31
9.1 Variant list validators..................................31
9.2 Structured entity tags...................................31
9.3 Assigning entity tags to variants........................32
9 Cache validators...........................................31
9.1 Variant list validators..................................31
9.2 Structured entity tags...................................31
9.3 Assigning entity tags to variants........................32
10 Content negotiation responses..............................32
10.1 List response...........................................33
10.2 Choice response.........................................34
10.3 Adhoc response..........................................37
10.4 Reusing the Alternates header...........................38
10.5 Extracting a normal response from a choice response.....39
10.6 Elaborate Vary headers..................................39
10.6.1 Construction of an elaborate Vary header..............40
10.6.2 Caching of an elaborate Vary header...................41
10.7 Adding an Expires header for HTTP/1.0 compatibility.....41
10.8 Negotiation on content encoding.........................41
10 Content negotiation responses..............................32
10.1 List response...........................................33
10.2 Choice response.........................................34
10.3 Adhoc response..........................................37
10.4 Reusing the Alternates header...........................38
10.5 Extracting a normal response from a choice response.....39
10.6 Elaborate Vary headers..................................39
10.6.1 Construction of an elaborate Vary header..............40
10.6.2 Caching of an elaborate Vary header...................41
10.7 Adding an Expires header for HTTP/1.0 compatibility.....41
10.8 Negotiation on content encoding.........................41
11 User agent support for transparent negotiation.............42
11.1 Handling of responses...................................42
11.2 Presentation of a transparently negotiated resource.....42
11 User agent support for transparent negotiation.............42
11.1 Handling of responses...................................42
11.2 Presentation of a transparently negotiated resource.....42
12 Origin server support for transparent negotiation..........43
12.1 Requirements............................................43
12.2 Negotiation on transactions other than GET and HEAD.....45
12 Origin server support for transparent negotiation..........43
12.1 Requirements............................................43
12.2 Negotiation on transactions other than GET and HEAD.....45
13 Proxy support for transparent negotiation..................45
13 Proxy support for transparent negotiation..................45
14 Security and privacy considerations........................46
14.1 Accept- headers revealing personal information..........46
14.2 Spoofing of responses from variant resources............47
14.3 Security holes revealed by negotiation..................47
14 Security and privacy considerations........................46
14.1 Accept- headers revealing personal information..........46
14.2 Spoofing of responses from variant resources............47
14.3 Security holes revealed by negotiation..................47
15 Internationalization considerations........................47
15 Internationalization considerations........................47
16 Acknowledgments............................................47
16 Acknowledgments............................................47
17 References.................................................48
17 References.................................................48
18 Authors' Addresses.........................................48
18 Authors' Addresses.........................................48
19 Appendix: Example of a local variant selection algorithm...49
19.1 Computing overall quality values........................49
19.2 Determining the result..................................51
19.3 Ranking dimensions......................................51
19 Appendix: Example of a local variant selection algorithm...49
19.1 Computing overall quality values........................49
19.2 Determining the result..................................51
19.3 Ranking dimensions......................................51
20 Appendix: feature negotiation examples.....................52
20.1 Use of feature tags.....................................52
20.2 Use of numeric feature tags.............................53
20.3 Feature tag design......................................53
20 Appendix: feature negotiation examples.....................52
20.1 Use of feature tags.....................................52
20.2 Use of numeric feature tags.............................53
20.3 Feature tag design......................................53
21 Appendix: origin server implementation considerations......54
21.1 Implementation with a CGI script........................54
21.2 Direct support by HTTP servers..........................55
21.3 Web publishing tools....................................55
21 Appendix: origin server implementation considerations......54
21.1 Implementation with a CGI script........................54
21.2 Direct support by HTTP servers..........................55
21.3 Web publishing tools....................................55
22 Appendix: Example of choice response construction..........55
22 Appendix: Example of choice response construction..........55
23 Full Copyright Statement...................................58
23 Full Copyright Statement...................................58
1 Introduction
1导言
HTTP allows web site authors to put multiple versions of the same information under a single URI. Each of these versions is called a `variant'. Transparent content negotiation is an extensible negotiation mechanism for automatically and efficiently retrieving the best variant when a GET or HEAD request is made. This enables the smooth deployment of new web data formats and markup tags.
HTTP允许网站作者将同一信息的多个版本放在一个URI下。这些版本中的每一个都称为“变体”。透明内容协商是一种可扩展的协商机制，用于在发出GET或HEAD请求时自动高效地检索最佳变体。这使得能够顺利部署新的web数据格式和标记标记。
This specification defines transparent content negotiation as an extension on top of the HTTP/1.1 protocol [1]. However, use of this extension does not require use of HTTP/1.1: transparent content negotiation can also be done if some or all of the parties are HTTP/1.0 [2] systems.
本规范将透明内容协商定义为HTTP/1.1协议[1]之上的扩展。但是，使用此扩展不需要使用HTTP/1.1：如果部分或所有参与方是HTTP/1.0[2]系统，也可以进行透明内容协商。
Transparent content negotiation is called `transparent' because it makes all variants which exist inside the origin server visible to outside parties.
透明内容协商被称为“透明”，因为它使源服务器内部存在的所有变体对外方可见。
Note: Some members of the IETF are currently undertaking a number of activities which are loosely related to this experimental protocol. First, there is an effort to define a protocol-independent registry for feature tags. The intention is that this experimental protocol will be one of the clients of the registry. Second, some research is being done on content negotiation systems for other transport protocols (like internet mail and internet fax) and on generalized negotiation systems for multiple transport protocols. At the time of writing, it is unclear if or when this research will lead to results in the form of complete negotiation system specifications. It is also unclear to which extent possible future specifications can or will re-use elements of this experimental protocol.
注：IETF的一些成员目前正在开展一些与该实验协议松散相关的活动。首先，需要为功能标签定义一个独立于协议的注册表。其目的是让这个实验性协议成为注册中心的客户机之一。其次，正在对其他传输协议（如internet邮件和internet传真）的内容协商系统和多个传输协议的通用协商系统进行一些研究。在撰写本文时，尚不清楚这项研究是否或何时会以完整的谈判系统规范的形式产生结果。还不清楚未来规范在多大程度上可以或将重复使用该实验协议的元素。
The addition of content negotiation to the web infrastructure has been considered important since the early days of the web. Among the expected benefits of a sufficiently powerful system for content negotiation are
从web的早期开始，将内容协商添加到web基础结构中就被认为很重要。功能强大的内容协商系统的预期好处包括
* smooth deployment of new data formats and markup tags will allow graceful evolution of the web
* 顺利部署新的数据格式和标记将允许web的优雅发展
* eliminating the need to choose between a `state of the art multimedia homepage' and one which can be viewed by all web users
* 无需在“最先进的多媒体主页”和可供所有网络用户浏览的主页之间进行选择
* enabling good service to a wider range of browsing platforms (from low-end PDA's to high-end VR setups)
* 为更广泛的浏览平台（从低端PDA到高端VR设置）提供优质服务
* eliminating error-prone and cache-unfriendly User-Agent based negotiation
* 消除易出错和缓存不友好的基于用户代理的协商
* enabling construction of sites without `click here for the X version' links
* 无需“单击此处获取X版本”链接即可构建站点
* internationalization, and the ability to offer multi-lingual content without a bias towards one language.
* 国际化，以及在不偏袒一种语言的情况下提供多语言内容的能力。
2 Terminology
2术语
The words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119 [4].
本文件中的“必须”、“不得”、“应该”、“不应该”和“可以”应按照RFC 2119[4]中的说明进行解释。
This specification uses the term `header' as an abbreviation for for `header field in a request or response message'.
本规范使用术语“header”作为“请求或响应消息中的header字段”的缩写。
This specification mostly uses the terminology of the HTTP/1.1 specification [1]. For the convenience of the reader, this section reproduces some key terminology definition from [1].
本规范主要使用HTTP/1.1规范[1]的术语。为了方便读者，本节复制了[1]中的一些关键术语定义。
request An HTTP request message.
请求HTTP请求消息。
response An HTTP response message.
响应HTTP响应消息。
resource A network data object or service that can be identified by a URI. Resources may be available in multiple representations (e.g. multiple languages, data formats, size, resolutions) or vary in other ways.
资源可以由URI标识的网络数据对象或服务。资源可能有多种表示形式（例如，多种语言、数据格式、大小、分辨率）或以其他方式变化。
content negotiation The mechanism for selecting the appropriate representation when servicing a request.
内容协商在为请求提供服务时选择适当表示的机制。
client A program that establishes connections for the purpose of sending requests.
客户端为发送请求而建立连接的程序。
user agent The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
用户代理发起请求的客户端。这些工具通常是浏览器、编辑器、爬行器（web遍历机器人）或其他最终用户工具。
server An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
服务器一种应用程序，它接受连接，以便通过发送回响应来服务请求。任何给定的程序都可以既是客户机又是服务器；我们对这些术语的使用仅指程序为特定连接执行的角色，而不是指程序的总体功能。同样，任何服务器都可以充当源服务器、代理、网关或隧道，根据每个请求的性质进行切换。
origin server The server on which a given resource resides or is to be created.
源服务器给定资源所在或将要创建的服务器。
proxy An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy must implement both the client and server requirements of this specification.
代理一种中间程序，它既是服务器又是客户端，用于代表其他客户端发出请求。请求由内部提供服务，或者通过将请求传递到其他服务器（可能需要翻译）来提供服务。代理必须实现本规范的客户机和服务器要求。
age The age of a response is the time since it was sent by, or successfully validated with, the origin server.
年龄响应的年龄是自原始服务器发送响应或使用原始服务器成功验证响应以来的时间。
fresh A response is fresh if its age has not yet exceeded its freshness lifetime.
新鲜如果响应的年龄尚未超过其新鲜度寿命，则该响应是新鲜的。
transparently negotiable resource A resource, identified by a single URI, which has multiple representations (variants) associated with it. When servicing a request on its URI, it allows selection of the best representation using the transparent content negotiation mechanism. A transparently negotiable resource always has a variant list bound to it, which can be represented as an Alternates header (defined in section 8.3).
透明可协商资源由单个URI标识的资源，具有多个与其关联的表示（变体）。当在其URI上为请求提供服务时，它允许使用透明内容协商机制选择最佳表示。透明可协商的资源总是绑定有一个变量列表，可以表示为一个备选标头（定义见第8.3节）。
variant list A list containing variant descriptions, which can be bound to a transparently negotiable resource.
变量列表包含变量描述的列表，可以绑定到透明可协商的资源。
variant description A machine-readable description of a variant resource, usually found in a variant list. A variant description contains the variant resource URI and various attributes which describe properties of the variant. Variant descriptions are defined in section 5.
变体描述变体资源的机器可读描述，通常在变体列表中找到。变量描述包含变量资源URI和描述变量属性的各种属性。第5节定义了变型说明。
variant resource A resource from which a variant of a negotiable resource can be retrieved with a normal HTTP/1.x GET request, i.e. a GET request which does not use transparent content negotiation.
variant resource可通过正常HTTP/1.x GET请求（即不使用透明内容协商的GET请求）检索可协商资源变体的资源。
neighboring variant A variant resource is called a neighboring variant resource of some transparently negotiable HTTP resource if the variant resource has a HTTP URL, and if the absolute URL of the variant resource up to its last slash equals the absolute URL of the negotiable resource up to its last slash, where equality is determined with the URI comparison rules in section 3.2.3 of [1]. The property of being a neighboring variant is important because of security considerations (section 14.2). Not all variants of a negotiable resource need to be neighboring variants. However, access to neighboring variants can be more highly optimized by the use of remote variant selection algorithms (section 7) and choice responses (section 10.2).
相邻变体如果变体资源具有HTTP URL，并且变体资源到其最后一个斜杠的绝对URL等于可协商资源到其最后一个斜杠的绝对URL，则变体资源称为某个透明可协商HTTP资源的相邻变体资源，其中等式由[1]第3.2.3节中的URI比较规则确定。出于安全考虑，相邻变体的属性很重要（第14.2节）。并非可协商资源的所有变体都需要是相邻的变体。然而，通过使用远程变量选择算法（第7节）和选择响应（第10.2节），可以更高度地优化对相邻变量的访问。
remote variant selection algorithm A standardized algorithm by which a server can sometimes choose a best variant on behalf of a negotiating user agent. The algorithm typically computes whether the Accept- headers in the request contain sufficient information to allow a choice, and if so, which variant is the best variant. The use of a remote algorithm can speed up the negotiation process.
远程变量选择算法服务器有时可以代表协商用户代理选择最佳变量的标准化算法。该算法通常计算请求中的Accept-Header是否包含足够的信息以允许选择，如果是，那么哪个变量是最好的变量。使用远程算法可以加快协商过程。
list response A list response returns the variant list of the negotiable resource, but no variant data. It can be generated when the server does not want to, or is not allowed to, return a particular best variant for the request. List responses are defined in section 10.1.
列表响应列表响应返回可协商资源的变量列表，但不返回变量数据。当服务器不想或不允许为请求返回特定的最佳变体时，可以生成该请求。第10.1节定义了列表响应。
choice response A choice response returns a representation of the best variant for the request, and may also return the variant list of the negotiable resource. It can be generated when the server has sufficient information to be able to choose the best variant on behalf the user agent, but may only be generated if this best variant is a neighboring variant. Choice responses are defined in section 10.2.
选择响应选择响应返回请求的最佳变体的表示，还可以返回可协商资源的变体列表。当服务器有足够的信息能够代表用户代理选择最佳变体时，可以生成该变量，但只有当该最佳变体是相邻变体时，才可以生成该变量。第10.2节定义了选择响应。
adhoc response An adhoc response can be sent by an origin server as an extreme measure, to achieve compatibility with a non-negotiating or buggy client if this compatibility cannot be achieved by sending a list or choice response. There are very little requirements on the contents of an adhoc response. Adhoc responses are defined in section 10.3.
临时响应如果无法通过发送列表或选择响应来实现兼容性，则原始服务器可以发送临时响应作为一种极端措施，以实现与非协商或有问题的客户端的兼容性。对临时响应的内容要求很少。第10.3节定义了临时响应。
Accept- headers The request headers: Accept, Accept-Charset, Accept-Language, and Accept-Features.
Accept-headers请求头：Accept、Accept字符集、Accept语言和Accept功能。
supports transparent content negotiation From the viewpoint of an origin server or proxy, a user agent supports transparent content negotiation if and only if it sends a Negotiate header (section 8.4) which indicates such support.
支持透明内容协商从源服务器或代理的角度来看，用户代理支持透明内容协商当且仅当其发送指示此类支持的协商标头（第8.4节）时。
server-side override If a request on a transparently negotiated resource is made by a client which supports transparent content negotiation, an origin server is said to perform a server-side override if the server ignores the directives in the Negotiate request header, and instead uses a custom algorithm to choose an appropriate response. A server-side override can sometimes be used to work around known client bugs. It could also be used by protocol extensions on top of transparent content negotiation.
服务器端覆盖如果透明协商资源上的请求是由支持透明内容协商的客户端发出的，则如果服务器忽略协商请求头中的指令，而是使用自定义算法选择适当的响应，则称源服务器执行服务器端覆盖。服务器端覆盖有时可用于解决已知的客户端错误。它也可以被透明内容协商之上的协议扩展使用。
3 Notation
3符号
The version of BNF used in this document is taken from [1], and many of the nonterminals used are defined in [1]. Note that the underlying charset is US-ASCII.
本文档中使用的BNF版本取自[1]，并且[1]中定义了许多使用的非终端。请注意，底层字符集是US-ASCII。
One new BNF construct is added:
添加了一个新的BNF构造：
1%rule
1%规则
stands for one or more instances of "rule", separated by whitespace:
表示“规则”的一个或多个实例，用空格分隔：
1%rule = rule *( 1*LWS rule )
1%rule = rule *( 1*LWS rule )
This specification also introduces
本规范还介绍了
number = 1*DIGIT
number = 1*DIGIT
short-float = 1*3DIGIT [ "." 0*3DIGIT ]
short-float = 1*3DIGIT [ "." 0*3DIGIT ]
This specification uses the same conventions as in [1] (see section 1.2 of [1]) for defining the significance of each particular requirement.
本规范使用与[1]中相同的约定（见[1]第1.2节）来定义每个特定要求的重要性。
4 Overview
4概述
This section gives an overview of transparent content negotiation. It starts with a more general discussion of negotiation as provided by HTTP.
本节概述了透明内容协商。它首先对HTTP提供的协商进行更一般性的讨论。
HTTP/1.1 allows web site authors to put multiple versions of the same information under a single resource URI. Each of these versions is called a `variant'. For example, a resource http://x.org/paper could bind to three different variants of a paper:
HTTP/1.1允许网站作者将同一信息的多个版本放在单个资源URI下。这些版本中的每一个都称为“变体”。例如，资源http://x.org/paper 可以绑定到纸张的三种不同变体：
1. HTML, English 2. HTML, French 3. Postscript, English
1. HTML，英语2。HTML，法语3。附言，英文
Content negotiation is the process by which the best variant is selected if the resource is accessed. The selection is done by matching the properties of the available variants to the capabilities of the user agent and the preferences of the user.
内容协商是在访问资源时选择最佳变体的过程。选择是通过将可用变体的属性与用户代理的功能和用户的首选项相匹配来完成的。
It has always been possible under HTTP to have multiple representations available for one resource, and to return the most appropriate representation for each subsequent request. However, HTTP/1.1 is the first version of HTTP which has provisions for doing this in a cache-friendly way. These provisions include the Vary response header, entity tags, and the If-None-Match request header.
在HTTP下，始终可以为一个资源提供多个表示，并为每个后续请求返回最合适的表示。但是，HTTP/1.1是HTTP的第一个版本，它规定了以缓存友好的方式执行此操作。这些规定包括Vary响应头、实体标记和If None匹配请求头。
The HTTP/1.0 protocol elements allow for a negotiation scheme as follows:
HTTP/1.0协议元素允许以下协商方案：
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
< ----------------------------------
| GET http://x.org/paper
| Accept- headers
choose
|
---------------------------------- >
Best variant
< ----------------------------------
| GET http://x.org/paper
| Accept- headers
choose
|
---------------------------------- >
Best variant
When the resource is accessed, the user agent sends (along with its request) various Accept- headers which express the user agent capabilities and the user preferences. Then the origin server uses these Accept- headers to choose the best variant, which is returned in the response.
当资源被访问时，用户代理发送（连同其请求）各种表示用户代理功能和用户首选项的Accept-Header。然后，源服务器使用这些Accept-Header来选择最佳变体，该变体将在响应中返回。
The biggest problem with this scheme is that it does not scale well. For all but the most minimal user agents, Accept- headers expressing all capabilities and preferences would be very large, and sending them in every request would be hugely inefficient, in particular because only a small fraction of the resources on the web have multiple variants.
这项计划最大的问题是它的规模不够大。对于除最小用户代理之外的所有代理，表示所有功能和首选项的Accept-Header都会非常大，在每个请求中发送它们的效率会非常低，特别是因为web上只有一小部分资源具有多个变体。
The transparent content negotiation scheme eliminates the need to send huge Accept- headers, and nevertheless allows for a selection process that always yields either the best variant, or an error message indicating that user agent is not capable of displaying any of the available variants.
透明内容协商方案无需发送巨大的接受头，但允许选择过程始终产生最佳变体，或显示错误消息，表明用户代理无法显示任何可用变体。
Under the transparent content negotiation scheme, the server sends a list with the available variants and their properties to the user agent. An example of a list with three variants is
在透明内容协商方案下，服务器向用户代理发送包含可用变体及其属性的列表。具有三种变体的列表示例如下：
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
The syntax and semantics of the variant descriptions in this list are covered in section 5. When the list is received, the user agent can choose the best variant and retrieve it. Graphically, the communication can be represented as follows:
本列表中变量描述的语法和语义见第5节。收到列表后，用户代理可以选择最佳变体并检索它。以图形方式，通信可以表示为：
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
< ----------------------------------
| GET http://x.org/paper
|
----------------------------------- > [list response]
return of list |
choose
|
< ----------------------------------
| GET http://x.org/paper.1
|
---------------------------------- > [normal response]
return of paper.1
< ----------------------------------
| GET http://x.org/paper
|
----------------------------------- > [list response]
return of list |
choose
|
< ----------------------------------
| GET http://x.org/paper.1
|
---------------------------------- > [normal response]
return of paper.1
The first response returning the list of variants is called a `list response'. The second response is a normal HTTP response: it does not contain special content negotiation related information. Only the user agent needs to know that the second request actually retrieves a variant. For the other parties in the communication, the second transaction is indistinguishable from a normal HTTP transaction.
返回变体列表的第一个响应称为“列表响应”。第二个响应是正常的HTTP响应：它不包含特殊的内容协商相关信息。只有用户代理需要知道第二个请求实际上检索了一个变量。对于通信中的其他方来说，第二个事务与正常HTTP事务是无法区分的。
With this scheme, information about capabilities and preferences is only used by the user agent itself. Therefore, sending such information in large Accept- headers is unnecessary. Accept- headers do have a limited use in transparent content negotiation however; the sending of small Accept- headers can often speed up the negotiation process. This is covered in section 4.4.
使用此方案，有关功能和首选项的信息仅由用户代理本身使用。因此，不需要在大型Accept-Header中发送此类信息。然而，Accept-header在透明内容协商中的用途有限；发送小的Accept-Header通常可以加快协商过程。第4.4节对此进行了介绍。
List responses are covered in section 10.1. As an example, the list response in the above picture could be:
第10.1节介绍了列表响应。例如，上图中的列表响应可以是：
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
<h2>Multiple Choices:</h2>
<ul>
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
<h2>Multiple Choices:</h2>
<ul>
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
The Alternates header in the response contains the variant list. The Vary header is included to ensure correct caching by plain HTTP/1.1 caches (see section 10.6). The ETag header allows the response to be revalidated by caches, the Cache-Control header controls this revalidation. The HTML entity included in the response allows the user to select the best variant by hand if desired.
响应中的Alternates标头包含变量列表。包含Vary头以确保通过普通HTTP/1.1缓存进行正确的缓存（参见第10.6节）。ETag头允许通过缓存重新验证响应，缓存控制头控制此重新验证。响应中包含的HTML实体允许用户根据需要手动选择最佳变体。
The basic transparent negotiation scheme involves two HTTP transactions: one to retrieve the list, and a second one to retrieve the chosen variant. There are however several ways to `cut corners' in the data flow path of the basic scheme.
基本的透明协商方案涉及两个HTTP事务：一个用于检索列表，另一个用于检索所选变量。然而，在基本方案的数据流路径中有几种“捷径”方法。
First, caching proxies can cache both variant lists and variants. Such caching can reduce the communication overhead, as shown in the following example:
首先，缓存代理可以缓存变量列表和变量。这种缓存可以减少通信开销，如下例所示：
Server _____ proxy _____ proxy __________ user
x.org cache cache agent
Server _____ proxy _____ proxy __________ user
x.org cache cache agent
< --------------
| GET ../paper
|
has the list
in cache
|
------------- > [list response]
list |
|
choose
|
< --------------------------
| GET ../paper.1
|
has the variant
in cache
|
-------------------------- > [normal response]
return of paper.1
< --------------
| GET ../paper
|
has the list
in cache
|
------------- > [list response]
list |
|
choose
|
< --------------------------
| GET ../paper.1
|
has the variant
in cache
|
-------------------------- > [normal response]
return of paper.1
Second, the user agent can send small Accept- headers, which may contain enough information to allow the server to choose the best variant and return it directly.
其次，用户代理可以发送小的Accept-Header，其中可能包含足够的信息，允许服务器选择最佳变体并直接返回。
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
Server _____ proxy _____ proxy _____ user
x.org cache cache agent
< ----------------------------------
| GET http://x.org/paper
| small Accept- headers
|
able to choose on
behalf of user agent
|
---------------------------------- > [choice response]
return of paper.1 and list
< ----------------------------------
| GET http://x.org/paper
| small Accept- headers
|
able to choose on
behalf of user agent
|
---------------------------------- > [choice response]
return of paper.1 and list
This choosing based on small Accept- headers is done with a `remote variant selection algorithm'. Such an algorithm takes the variant list and the Accept- headers as input. It then computes whether the Accept- headers contain sufficient information to choose on behalf of the user agent, and if so, which variant is the best variant. If the best variant is a neighboring variant, it may be returned, together with the variant list, in a choice response.
这种基于小接受头的选择是通过“远程变量选择算法”完成的。这种算法将变量列表和接受头作为输入。然后，它计算Accept-Header是否包含足够的信息以代表用户代理进行选择，如果是，那么哪个变量是最佳的变量。如果最佳变体是相邻的变体，则可在选择响应中将其与变体列表一起返回。
A server may only choose on behalf of a user agent supporting transparent content negotiation if the user agent explicitly allows the use of a particular remote variant selection algorithm in the Negotiate request header. User agents with sophisticated internal variant selection algorithms may want to disallow a remote choice, or may want to allow it only when retrieving inline images. If the local algorithm of the user agent is superior in only some difficult areas of negotiation, it is possible to enable the remote algorithm for the easy areas only. More information about the use of a remote variant selection algorithm can be found in [3].
如果用户代理明确允许在协商请求报头中使用特定的远程变量选择算法，则服务器只能代表支持透明内容协商的用户代理进行选择。具有复杂内部变量选择算法的用户代理可能希望禁止远程选择，或者可能希望仅在检索内联图像时才允许远程选择。如果用户代理的本地算法仅在某些困难的协商领域具有优势，则可以仅在容易的领域启用远程算法。有关使用远程变量选择算法的更多信息，请参见[3]。
Choice responses are covered in section 10.2. For example, the choice response in the above picture could be:
第10.2节介绍了选择回答。例如，上图中的选择响应可以是：
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
<title>A paper about ....
<title>A paper about ....
Finally, the above two kinds of optimization can be combined; a caching proxy which has the list will sometimes be able to choose on behalf of the user agent. This could lead to the following communication pattern:
最后，可以将上述两种优化结合起来；具有该列表的缓存代理有时可以代表用户代理进行选择。这可能导致以下通信模式：
Server _____ proxy _____ proxy __________ user
x.org cache cache agent
Server _____ proxy _____ proxy __________ user
x.org cache cache agent
< ---------------
| GET ../paper
| small Accept
|
able to choose
on behalf
|
< ----------
| GET ../paper.1
|
---------- > [normal response]
paper.1 |
---------------- > [choice response]
paper.1 and list
< ---------------
| GET ../paper
| small Accept
|
able to choose
on behalf
|
< ----------
| GET ../paper.1
|
---------- > [normal response]
paper.1 |
---------------- > [choice response]
paper.1 and list
Note that this cutting of corners not only saves bandwidth, it also eliminates delays due to packet round trip times, and reduces the load on the origin server.
请注意，这种捷径不仅节省了带宽，还消除了由于数据包往返时间造成的延迟，并减少了源服务器上的负载。
To handle requests from user agents which do not support transparent content negotiation, this specification allows the origin server to revert to a HTTP/1.0 style negotiation scheme. The specification of heuristics for such schemes is beyond the scope of this document.
为了处理来自不支持透明内容协商的用户代理的请求，此规范允许源服务器恢复为HTTP/1.0样式的协商方案。此类方案的启发式规范超出了本文件的范围。
It is always possible for a user agent to retrieve the variant list which is bound to a negotiable resource. The user agent can use this list to make available a menu of all variants and their characteristics to the user. Such a menu allows the user to randomly browse other variants, and makes it possible to manually correct any sub-optimal choice made by the automatic negotiation process.
用户代理始终可以检索绑定到可协商资源的变量列表。用户代理可以使用此列表向用户提供所有变体及其特征的菜单。这样的菜单允许用户随机浏览其他变体，并允许手动纠正自动协商过程中做出的任何次优选择。
Transparent content negotiation defines four dimensions of negotiation:
透明内容协商定义了协商的四个维度：
1. Media type (MIME type) 2. Charset 3. Language 4. Features
1. 媒体类型（MIME类型）2。字符集3。语言4。特征
The first three dimensions have traditionally been present in HTTP. The fourth dimension is added by this specification. Additional dimensions, beyond the four mentioned above, could be added by future specifications.
前三个维度传统上存在于HTTP中。本规范增加了第四个尺寸。除上述四个尺寸外，其他尺寸可根据未来规范添加。
Negotiation on the content encoding of a response (gzipped, compressed, etc.) is left outside of the realm of transparent negotiation. See section 10.8 for more information.
关于响应内容编码的协商（gzip、压缩等）不属于透明协商的范畴。更多信息请参见第10.8节。
Feature negotiation intends to provide for all areas of negotiation not covered by the type, charset, and language dimensions. Examples are negotiation on
功能协商旨在提供类型、字符集和语言维度未涵盖的所有协商领域。这方面的谈判就是一个例子
* HTML extensions * Extensions of other media types * Color capabilities of the user agent * Screen size * Output medium (screen, paper, ...) * Preference for speed vs. preference for graphical detail
* HTML扩展*其他媒体类型的扩展*用户代理的颜色功能*屏幕大小*输出媒体（屏幕、纸张等）*速度偏好与图形细节偏好
The feature negotiation framework (section 6) is the principal means by which transparent negotiation offers extensibility; a new dimension of negotiation (really a sub-dimension of the feature dimension) can be added without the need for a new standards effort by the simple registration of a `feature tag'.
特性协商框架（第6节）是透明协商提供可扩展性的主要手段；通过简单地注册“功能标签”，可以添加新的协商维度（实际上是功能维度的子维度），而无需新的标准工作。
As a general rule, variant lists should be short: it is expected that a typical transparently negotiable resource will have 2 to 10 variants, depending on its purpose. Variant lists should be short for a number of reasons:
一般来说，变体列表应该简短：根据其用途，一个典型的透明可协商资源应该有2到10个变体。变体列表应简短，原因如下：
1. The user must be able to pick a variant by hand to correct a bad automatic choice, and this is more difficult with a long variant list.
1. 用户必须能够手动选择一个变体来纠正错误的自动选择，而这对于一个长的变体列表来说更为困难。
2. A large number of variants will decrease the efficiency of internet proxy caches.
2. 大量变体将降低internet代理缓存的效率。
3. Long variant lists will make some transparently negotiated responses longer.
3. 长的变量列表将使一些透明协商的响应更长。
In general, it is not desirable to create a transparently negotiable resource with hundreds of variants in order to fine-tune the graphical presentation of a resource. Any graphical fine-tuning should be done, as much as possible, by using constructs which act at the user agent side, for example
通常，不希望创建具有数百个变体的透明可协商资源来微调资源的图形表示。任何图形微调都应该尽可能地通过使用在用户代理端起作用的结构来完成，例如
<center><img src=titlebanner.gif width=100%
alt="MegaBozo Corp"></center>
<center><img src=titlebanner.gif width=100%
alt="MegaBozo Corp"></center>
In order to promote user agent side fine tuning, which is more scalable than fine tuning over the network, user agents which implement a scripting language for content rendering are encouraged to make the availability of this language visible for transparent content negotiation, and to allow rendering scripts to access the capabilities and preferences data used for content negotiation, as far as privacy considerations permit this.
为了促进用户代理端微调（比网络微调更具可扩展性），鼓励实现内容呈现脚本语言的用户代理将此语言的可用性用于透明内容协商，并允许渲染脚本访问用于内容协商的功能和首选项数据，只要隐私考虑允许。
The HTTP/1.x protocol suite allows for many different negotiation mechanisms. Transparent content negotiation specializes in scalable, interoperable negotiation of content representations at the HTTP level. It is intended that transparent negotiation can co-exist with other negotiation schemes, both open and proprietary, which cover different application domains or work at different points in the author-to-user chain. Ultimately, it will be up to the resource author to decide which negotiation mechanism, or combination of negotiation mechanisms, is most appropriate for the task at hand.
HTTP/1.x协议套件允许多种不同的协商机制。透明内容协商专门在HTTP级别对内容表示进行可伸缩、可互操作的协商。其目的是，透明协商可以与其他协商方案共存，包括开放和专有的协商方案，这些协商方案覆盖不同的应用程序域或在作者到用户链的不同点上工作。最终，将由资源作者决定哪种协商机制或协商机制的组合最适合手头的任务。
5 Variant descriptions
5变体描述
A variant can be described in a machine-readable way with a variant description.
变量可以通过变量描述以机器可读的方式进行描述。
variant-description =
"{" <"> URI <"> source-quality *variant-attribute"}"
variant-description =
"{" <"> URI <"> source-quality *variant-attribute"}"
source-quality = qvalue
source-quality = qvalue
variant-attribute = "{" "type" media-type "}"
| "{" "charset" charset "}"
| "{" "language" 1#language-tag "}"
| "{" "length" 1*DIGIT "}"
| "{" "features" feature-list "}"
| "{" "description"
quoted-string [ language-tag ] "}"
| extension-attribute
variant-attribute = "{" "type" media-type "}"
| "{" "charset" charset "}"
| "{" "language" 1#language-tag "}"
| "{" "length" 1*DIGIT "}"
| "{" "features" feature-list "}"
| "{" "description"
quoted-string [ language-tag ] "}"
| extension-attribute
extension-attribute = "{" extension-name extension-value "}"
extension-name = token
extension-value = *( token | quoted-string | LWS
| extension-specials )
extension-attribute = "{" extension-name extension-value "}"
extension-name = token
extension-value = *( token | quoted-string | LWS
| extension-specials )
extension-specials =
<any element of tspecials except <"> and "}">
extension-specials =
<any element of tspecials except <"> and "}">
The feature-list syntax is defined in section 6.4.
第6.4节定义了功能列表语法。
Examples are
例如
{"paper.2" 0.7 {type text/html} {language fr}}
{"paper.2" 0.7 {type text/html} {language fr}}
{"paper.5" 0.9 {type text/html} {features tables}}
{"paper.5" 0.9 {type text/html} {features tables}}
{"paper.1" 0.001}
{“paper.1”0.001}
The various attributes which can be present in a variant description are covered in the subsections below. Each attribute may appear only once in a variant description.
变量描述中可能存在的各种属性将在下面的小节中介绍。每个属性在变量描述中只能出现一次。
The URI attribute gives the URI of the resource from which the variant can be retrieved with a GET request. It can be absolute or relative to the Request-URI. The variant resource may vary (on the
URI属性给出了资源的URI，通过GET请求可以从中检索变量。它可以是绝对的，也可以是相对于请求URI的。变体资源可能会有所不同（在
Cookie request header, for example), but MUST NOT engage in transparent content negotiation itself.
例如，Cookie请求头），但不能参与透明内容协商本身。
The source-quality attribute gives the quality of the variant, as a representation of the negotiable resource, when this variant is rendered with a perfect rendering engine on the best possible output medium.
当在最佳输出介质上使用完美的渲染引擎渲染此变量时，“源质量”属性提供变量的质量，作为可协商资源的表示。
If the source-quality is less than 1, it often expresses a quality degradation caused by a lossy conversion to a particular data format. For example, a picture originally in JPEG form would have a lower source quality when translated to the XBM format, and a much lower source quality when translated to an ASCII-art variant. Note however, that degradation is a function of the source; an original piece of ASCII-art may degrade in quality if it is captured in JPEG form.
如果源质量小于1，则通常表示由于有损转换到特定数据格式而导致的质量下降。例如，原始JPEG格式的图片在转换为XBM格式时的源质量较低，而在转换为ASCII艺术变体时的源质量要低得多。然而，请注意，退化是源的函数；如果以JPEG格式捕获原始ASCII艺术作品，其质量可能会降低。
The source-quality could also represent a level of quality caused by skill of language translation, or ability of the used media type to capture the intended artistic expression.
源质量也可以表示由语言翻译技能或所用媒体类型捕捉预期艺术表达的能力引起的质量水平。
Servers should use the following table a guide when assigning source quality values:
分配源质量值时，服务器应使用下表作为指南：
1.000 perfect representation 0.900 threshold of noticeable loss of quality 0.800 noticeable, but acceptable quality reduction 0.500 barely acceptable quality 0.300 severely degraded quality 0.000 completely degraded quality
1.000完美表示0.900明显质量损失阈值0.800明显，但可接受质量降低0.500勉强可接受质量0.300严重降级质量0.000完全降级质量
The same table can be used by local variant selection algorithms (see appendix 19) when assigning degradation factors for different content rendering mechanisms. Note that most meaningful values in this table are close to 1. This is due to the fact that quality factors are generally combined by multiplying them, not by adding them.
当为不同的内容呈现机制分配降级因子时，本地变量选择算法（参见附录19）可以使用相同的表。请注意，此表中最有意义的值接近1。这是因为质量因素通常是通过相乘而不是相加来组合的。
When assigning source-quality values, servers should not account for the size of the variant and its impact on transmission and rendering delays; the size of the variant should be stated in the length attribute and any size-dependent calculations should be done by the variant selection algorithm. Any constant rendering delay for a particular media type (for example due to the startup time of a helper application) should be accounted for by the user agent, when assigning a quality factor to that media type.
分配源质量值时，服务器不应考虑变量的大小及其对传输和渲染延迟的影响；变量的大小应在“长度”属性中说明，任何与大小相关的计算都应通过变量选择算法完成。在为特定媒体类型指定质量因子时，用户代理应考虑特定媒体类型的任何恒定呈现延迟（例如，由于助手应用程序的启动时间）。
The type attribute of a variant description carries the same information as its Content-Type response header counterpart defined in [1], except for any charset information, which MUST be carried in the charset attribute. For, example, the header
变量描述的type属性包含与[1]中定义的内容类型响应头对应项相同的信息，但任何字符集信息除外，这些信息必须包含在charset属性中。例如，标题
Content-Type: text/html; charset=ISO-8859-4
Content-Type: text/html; charset=ISO-8859-4
has the counterpart attributes
具有对应的属性
{type text/html} {charset ISO-8859-4}
{type text/html} {charset ISO-8859-4}
The language and length attributes carry the same information as their Content-* response header counterparts in [1]. The length attribute, if present, MUST thus reflect the length of the variant alone, and not the total size of the variant and any objects inlined or embedded by the variant.
language和length属性包含与[1]中对应的Content-*响应标题相同的信息。因此，“长度”属性（如果存在）必须仅反映变量的长度，而不是变量和变量内联或嵌入的任何对象的总大小。
Though all of these attributes are optional, it is often desirable to include as many attributes as possible, as this will increase the quality of the negotiation process.
尽管所有这些属性都是可选的，但通常希望包含尽可能多的属性，因为这将提高谈判过程的质量。
Note: A server is not required to maintain a one-to-one correspondence between the attributes in the variant description and the Content-* headers in the variant response. For example, if the variant description contains a language attribute, the response does not necessarily have to contain a Content-Language header. If a Content-Language header is present, it does not have to contain an exact copy of the information in the language attribute.
注意：服务器不需要在变量描述中的属性和变量响应中的Content-*头之间保持一对一的对应关系。例如，如果变量描述包含语言属性，则响应不一定必须包含内容语言标题。如果存在内容语言标题，则不必在“语言”属性中包含信息的精确副本。
The features attribute specifies how the presence or absence of particular feature tags in the user agent affects the overall quality of the variant. This attribute is covered in section 6.4.
features属性指定用户代理中特定功能标记的存在或不存在如何影响变体的总体质量。第6.4节介绍了该属性。
The description attribute gives a textual description of the variant. It can be included if the URI and normal attributes of a variant are considered too opaque to allow interpretation by the user. If a user agent is showing a menu of available variants compiled from a variant list, and if a variant has a description attribute, the user agent SHOULD show the description attribute of the variant instead of showing the normal attributes of the variant. The description field uses the UTF-8 character encoding scheme [5], which is a superset of
description属性提供变量的文本描述。如果一个变量的URI和normal属性被认为过于不透明，不允许用户进行解释，则可以包含它。如果用户代理显示从变量列表编译的可用变量菜单，并且变量具有描述属性，则用户代理应显示变量的描述属性，而不是显示变量的正常属性。描述字段使用UTF-8字符编码方案[5]，它是
US-ASCII, with ""%" HEX HEX" encoding. The optional language tag MAY be used to specify the language used in the description text.
US-ASCII，采用“%”十六进制编码。可选语言标记可用于指定描述文本中使用的语言。
The extension-attribute allows future specifications to incrementally define dimensions of negotiation which cannot be created by using the feature negotiation framework, and eases content negotiation experiments. In experimental situations, servers MUST ONLY generate extension-attributes whose names start with "x-". User agents SHOULD ignore all extension attributes they do not recognize. Proxies MUST NOT run a remote variant selection algorithm if an unknown extension attribute is present in the variant list.
扩展属性允许将来的规范以增量方式定义协商的维度，这些维度无法使用功能协商框架创建，并简化了内容协商实验。在实验情况下，服务器必须只生成名称以“x-”开头的扩展属性。用户代理应该忽略所有他们无法识别的扩展属性。如果变量列表中存在未知的扩展属性，则代理不得运行远程变量选择算法。
6 Feature negotiation
6特征协商
This section defines the feature negotiation mechanism. Feature negotiation has been introduced in section 4.8. Appendix 19 contains examples of feature negotiation.
本节定义了功能协商机制。第4.8节介绍了功能协商。附录19包含功能协商的示例。
A feature tag (ftag) identifies something which can be negotiated on, for example a property (feature) of a representation, a capability (feature) of a user agent, or the preference of a user for a particular type of representation. The use of feature tags need not be limited to transparent content negotiation, and not every feature tag needs to be usable in the HTTP transparent content negotiation framework.
特征标签（ftag）标识可以协商的内容，例如表示的属性（特征）、用户代理的能力（特征）或用户对特定类型表示的偏好。特性标记的使用不需要局限于透明内容协商，并且并非每个特性标记都需要在HTTP透明内容协商框架中可用。
ftag = token | quoted-string
ftag=标记|带引号的字符串
Note: A protocol-independent system for feature tag registration is currently being developed in the IETF. This specification does not define any feature tags. In experimental situations, the use of tags which start with "x." is encouraged.
注：IETF目前正在开发一个与协议无关的功能标签注册系统。本规范未定义任何特征标记。在实验情况下，鼓励使用以“x”开头的标签。
Feature tags are used in feature sets (section 6.2) and in feature predicates (section 6.3). Feature predicates are in turn used in features attributes (section 6.4), which are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).
特征标记用于特征集（第6.2节）和特征谓词（第6.3节）。特征谓词依次用于特征属性（第6.4节），用于变量描述（第5节）。变量描述可在备选标题中传输（第8.3节）。
The US-ASCII charset is used for feature tags. Feature tag comparison is case-insensitive. A token tag XYZ is equal to a quoted-string tag "XYZ". Examples are
US-ASCII字符集用于特征标记。功能标记比较不区分大小写。令牌标记XYZ等于带引号的字符串标记“XYZ”。例如
tables, fonts, blebber, wolx, screenwidth, colordepth
表格、字体、气泡、wolx、屏幕宽度、颜色深度
An example of the use of feature tags in a variant description is:
变量描述中使用特征标记的示例如下：
{"index.html" 1.0 {type text/html} {features tables frames}}
{"index.html" 1.0 {type text/html} {features tables frames}}
This specification follows general computing practice in that it places no restrictions on what may be called a feature. At the protocol level, this specification does not distinguish between different uses of feature tags: a tag will be processed in the same way, no matter whether it identifies a property, capability, or preference. For some tags, it may be fluid whether the tag represents a property, preference, or capability. For example, in content negotiation on web pages, a "textonly" tag would identify a capability of a text-only user agent, but the user of a graphical user agent may use this tag to specify that text-only content is preferred over graphical content.
本规范遵循一般计算实践，对所谓的特性没有任何限制。在协议级别，本规范不区分功能标签的不同用途：标签将以相同的方式进行处理，无论它是标识属性、功能还是首选项。对于某些标记，标记是否表示属性、首选项或功能可能是流动的。例如，在网页上的内容协商中，“textonly”标记将标识纯文本用户代理的功能，但是图形用户代理的用户可以使用该标记来指定纯文本内容优先于图形内容。
The definition of a feature tag may state that a feature tag can have zero, one, or more values associated with it. These values specialize the meaning of the tag. For example, a feature tag `paper' could be associated with the values `A4' and `A5'.
要素标记的定义可以说明要素标记可以有零个、一个或多个与其关联的值。这些值专门化标记的含义。例如，功能标签“纸张”可以与值“A4”和“A5”相关联。
tag-value = token | quoted-string
标记值=标记|带引号的字符串
The US-ASCII charset is used for feature tag values. Equality comparison for tag values MUST be done with a case-sensitive, octet-by-octet comparison, where any ""%" HEX HEX" encodings MUST be processed as in [1]. A token value XYZ is equal to a quoted-string value "XYZ".
US-ASCII字符集用于特征标记值。标记值的相等性比较必须使用区分大小写的八位字节逐八位字节比较进行，其中任何“%”十六进制编码都必须按照[1]中的方式进行处理。标记值XYZ等于带引号的字符串值“XYZ”。
The feature set of a user agent is a data structure which records the capabilities of the user agent and the preferences of the user.
用户代理的功能集是一种数据结构，它记录用户代理的功能和用户的首选项。
Feature sets are used by local variant selection algorithms (see appendix 19 for an example). A user agent can use the Accept-Features header (section 8.2) to make some of the contents of its feature set known to remote variant selection algorithms.
本地变量选择算法使用特征集（示例见附录19）。用户代理可以使用Accept Features标头（第8.2节）使远程变量选择算法知道其功能集的一些内容。
Structurally, a feature set is a possibly empty set, containing records of the form
从结构上讲，要素集可能是一个空集，包含表单的记录
( feature tag , set of feature tag values )
（要素标记，要素标记值集）
If a record with a feature tag is present in the set, this means that the user agent implements the corresponding capability, or that the user has expressed the corresponding preference.
如果集合中存在具有功能标记的记录，则表示用户代理实现了相应的功能，或者用户已表示了相应的首选项。
Each record in a feature set has a, possibly empty, set of tag values. For feature tags which cannot have values associated with it, this set is always empty. For feature tags which can have zero, one, or more values associated with it, this set contains those values currently associated with the tag. If the set of a feature tag T has the value V in it, it is said that `the tag T is present with the value V'.
要素集中的每个记录都有一组可能为空的标记值。对于无法关联值的要素标记，此集合始终为空。对于具有零个、一个或多个关联值的要素标记，此集合包含当前与标记关联的值。如果特征标签T的集合中有值V，则表示“标签T中有值V”。
This specification does not define a standard notation for feature sets. An example of a very small feature set, in a mathematical notation, is
本规范未定义功能集的标准符号。数学符号中非常小的功能集示例如下
{ ( "frames" , { } ) ,
( "paper" , { "A4" , "A5" } )
}
{ ( "frames" , { } ) ,
( "paper" , { "A4" , "A5" } )
}
As feature registration is expected to be an ongoing process, it is generally not possible for a user agent to know the meaning of all feature tags it can possibly encounter in a variant description. A user agent SHOULD treat all features tags unknown to it as absent from its feature set.
由于特征注册预计是一个持续的过程，用户代理通常不可能知道在变体描述中可能遇到的所有特征标记的含义。用户代理应将其未知的所有功能标记视为其功能集中不存在。
A user agent may change the contents of its feature set depending on the type of request, and may also update it to reflect changing conditions, for example a change in the window size. Therefore, when considering feature negotiation, one usually talks about `the feature set of the current request'.
用户代理可以根据请求的类型更改其功能集的内容，还可以更新它以反映不断变化的条件，例如窗口大小的变化。因此，在考虑特征协商时，人们通常谈论“当前请求的特征集”。
Feature predicates are predicates on the contents of feature sets. They appear in the features attribute of a variant description.
特征谓词是基于特征集内容的谓词。它们出现在变体描述的“特征”属性中。
fpred = [ "!" ] ftag
| ftag ( "=" | "!=" ) tag-value
| ftag "=" "[" numeric-range "]"
fpred = [ "!" ] ftag
| ftag ( "=" | "!=" ) tag-value
| ftag "=" "[" numeric-range "]"
numeric-range = [ number ] "-" [ number ]
numeric-range = [ number ] "-" [ number ]
Feature predicates are used in features attributes (section 6.4), which are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).
特性谓词用于特性属性（第6.4节），用于变量描述（第5节）。变量描述可在备选标题中传输（第8.3节）。
Examples of feature predicates are
特征谓词的示例包括
blebber, !blebber, paper=a4, colordepth=5, blex!=54,
dpi=[300-599], colordepth=[24-]
blebber, !blebber, paper=a4, colordepth=5, blex!=54,
dpi=[300-599], colordepth=[24-]
Using the feature set of the current request, a user agent SHOULD compute the truth value of the different feature predicates as follows.
使用当前请求的特性集，用户代理应该计算不同特性谓词的真值，如下所示。
ftag true if the feature is present, false otherwise
如果特征存在，则ftag为true，否则为false
!ftag true if the feature is absent, false otherwise
!如果特征缺失，则ftag为真，否则为假
ftag=V true if the feature is present with the value V, false otherwise,
如果特征值为V，则ftag=V true，否则为false，
ftag!=V true if the feature is not present with the value V, false otherwise,
自由贸易区=V如果特征不存在值V，则为true，否则为false，
ftag=[N-M] true if the feature is present with at least one numeric value, while the highest value with which it is present in the range N-M, false otherwise. If N is missing, the lower bound is 0. If M is missing, the upper bound is infinity.
ftag=[N-M]如果特征存在至少一个数值，则为true，而其存在的最高值在N-M范围内，否则为false。如果缺少N，则下限为0。如果M缺失，则上界为无穷大。
As an example, with the feature set
例如，使用功能集
{ ( "blex" , { } ),
( "colordepth" , { "5" } ),
( "UA-media" , { "stationary" } ),
( "paper" , { "A4", "A3" } ) ,
( "x-version" , { "104", "200" } )
}
{ ( "blex" , { } ),
( "colordepth" , { "5" } ),
( "UA-media" , { "stationary" } ),
( "paper" , { "A4", "A3" } ) ,
( "x-version" , { "104", "200" } )
}
the following predicates are true:
以下谓词为真：
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, UA-
media=stationary, UA-media!=screen, paper=A4, paper =!A0,
colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300]
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth, UA-
media=stationary, UA-media!=screen, paper=A4, paper =!A0,
colordepth=[ 4 - 6 ], x-version=[100-300], x-version=[200-300]
and the following predicates are false:
以下谓词为false：
!blex, blebber, colordepth=6, colordepth=foo, !colordepth,
screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA-
media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
!blex, blebber, colordepth=6, colordepth=foo, !colordepth,
screenwidth, screenwidth=640, screenwidth!=640, x-version=99, UA-
media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
The features attribute, for which section 5.1 defines the syntax
features属性，第5.1节为其定义了语法
"{" "features" feature-list "}"
{“功能”功能列表“}”
is used in a variant description to specify how the presence or absence of particular feature tags in the user agent affects the overall quality of the variant.
在变体描述中使用，以指定用户代理中特定功能标记的存在或不存在如何影响变体的总体质量。
feature-list = 1%feature-list-element
要素列表=1%要素列表元素
feature-list-element = ( fpred | fpred-bag )
[ ";" [ "+" true-improvement ]
[ "-" false-degradation ]
]
feature-list-element = ( fpred | fpred-bag )
[ ";" [ "+" true-improvement ]
[ "-" false-degradation ]
]
fpred-bag = "[" 1%fpred "]"
fpred bag=“[“1%fpred”]”
true-improvement = short-float false-degradation = short-float
真实改善=短期浮动错误降级=短期浮动
Features attributes are used in variant descriptions (section 5). Variant descriptions can be transmitted in Alternates headers (section 8.3).
特征属性用于变体描述（第5节）。变量描述可在备选标题中传输（第8.3节）。
Examples are:
例如：
{features !textonly [blebber !wolx] colordepth=3;+0.7}
{features !textonly [blebber !wolx] colordepth=3;+0.7}
{features !blink;-0.5 background;+1.5 [blebber !wolx];+1.4-0.8}
{features !blink;-0.5 background;+1.5 [blebber !wolx];+1.4-0.8}
The default value for the true-improvement is 1. The default value for the false-degradation is 0, or 1 if a true-improvement value is given.
真正改善的默认值为1。错误降级的默认值为0，如果给出了真正的改善值，则为1。
A user agent SHOULD, and a remote variant selection algorithm MUST compute the quality degradation factor associated with the features attribute by multiplying all quality degradation factors of the elements of the feature-list. Note that the result can be a factor greater than 1.
用户代理应该，远程变量选择算法必须通过乘以特征列表元素的所有质量降级因子来计算与特征属性相关联的质量降级因子。请注意，结果可以是大于1的系数。
A feature list element yields its true-improvement factor if the corresponding feature predicate is true, or if at least one element of the corresponding fpred-bag is true. The element yields its false-degradation factor otherwise.
如果对应的特征谓词为真，或者如果对应的fpred包中至少有一个元素为真，则特征列表元素将产生其真正的改善因子。否则，该元素将产生错误的退化因子。
7 Remote variant selection algorithms
7个远程变量选择算法
A remote variant selection algorithm is a standardized algorithm by which a server can choose a best variant on behalf of a negotiating user agent. The use of a remote algorithm can speed up the negotiation process by eliminating a request-response round trip.
远程变体选择算法是一种标准化算法，通过该算法，服务器可以代表协商用户代理选择最佳变体。使用远程算法可以通过消除请求-响应往返来加快协商过程。
A remote algorithm typically computes whether the Accept- headers in the request contain sufficient information to allow a choice, and if so, which variant is the best variant. This specification does not define any remote algorithms, but does define a mechanism to negotiate on the use of such algorithms.
远程算法通常计算请求中的Accept-Header是否包含足够的信息以允许选择，如果是，那么哪个变量是最好的变量。本规范未定义任何远程算法，但定义了协商使用此类算法的机制。
A version numbering scheme is used to distinguish between different remote variant selection algorithms.
版本编号方案用于区分不同的远程变量选择算法。
rvsa-version = major "." minor
rvsa版本=主要“.”次要
major = 1*4DIGIT
minor = 1*4DIGIT
major = 1*4DIGIT
minor = 1*4DIGIT
An algorithm with the version number X.Y, with Y>0, MUST be downwards compatible with all algorithms from X.0 up to X.Y. Downwards compatibility means that, if supplied with the same information, the newer algorithm MUST make the same choice, or a better choice, as the old algorithm. There are no compatibility requirements between algorithms with different major version numbers.
版本号为X.Y且Y>0的算法必须向下兼容从X.0到X.Y的所有算法。向下兼容意味着，如果提供相同的信息，较新的算法必须做出与旧算法相同的选择，或更好的选择。具有不同主要版本号的算法之间没有兼容性要求。
8 Content negotiation status codes and headers
8内容协商状态代码和标题
This specification adds one new HTTP status code, and introduces six new HTTP headers. It also extends the semantics of an existing HTTP/1.1 header.
该规范添加了一个新的HTTP状态代码，并引入了六个新的HTTP头。它还扩展了现有HTTP/1.1头的语义。
The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.
506状态代码表示服务器存在内部配置错误：所选变体资源被配置为参与透明内容协商本身，因此不是协商过程中的适当终点。
The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request. Servers can use this information when running a remote variant selection algorithm.
用户代理可以使用Accept Features请求标头提供有关当前请求的功能集中是否存在某些功能的信息。服务器可以在运行远程变量选择算法时使用此信息。
Note: the name `Accept-Features' for this header was chosen because of symmetry considerations with other Accept- headers, even though the Accept-Features header will generally not contain an exhaustive list of features which are somehow `accepted'. A more accurate name of this header would have been `Feature-Set-Info'.
注意：选择此标题的名称“Accept Features”是因为考虑到与其他Accept-header的对称性，即使Accept Features标题通常不包含以某种方式“Accept”的功能的详尽列表。此标题的更准确名称应为“功能集信息”。
Accept-Features = "Accept-Features" ":"
#( feature-expr *( ";" feature-extension ) )
Accept-Features = "Accept-Features" ":"
#( feature-expr *( ";" feature-extension ) )
feature-expr = [ "!" ] ftag
| ftag ( "=" | "!=" ) tag-value
| ftag "=" "{" tag-value "}"
| "*"
feature-expr = [ "!" ] ftag
| ftag ( "=" | "!=" ) tag-value
| ftag "=" "{" tag-value "}"
| "*"
feature-extension = token [ "=" ( token | quoted-string ) ]
特征扩展=标记[“=”（标记|带引号的字符串）]
No feature extensions are defined in this specification. An example is:
本规范中未定义任何功能扩展。例如：
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
paper = A4, paper!="A2", x-version=104, *
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
paper = A4, paper!="A2", x-version=104, *
The different feature expressions have the following meaning:
不同的要素表达式具有以下含义：
ftag ftag is present
自由贸易协定自由贸易协定已经存在
!ftag ftag is absent
!没有自由贸易协定
ftag=V ftag is present with the value V
ftag=V ftag值为V
ftag!=V ftag is present, but not with the value V
自由贸易区=V ftag存在，但不具有值V
ftag={V} ftag is present with the value V, and not with any other values
ftag={V}ftag与值V一起出现，而不与任何其他值一起出现
* the expressions in this header do not fully describe the feature set: feature tags not mentioned in this header may also be present, and, except for the case ftag={V}, tags may be present with more values than mentioned.
* 此标题中的表达式不完全描述功能集：此标题中未提及的功能标记也可能存在，并且，除了ftag={V}的情况外，标记可能存在的值可能多于所提及的值。
Absence of the Accept-Features header in a request is equivalent to the inclusion of
请求中缺少Accept Features标头相当于包含
Accept-Features: *
接受功能：*
By using the Accept-Features header, a remote variant selection algorithm can sometimes determine the truth value of a feature predicate on behalf of the user agent. For example, with the header
通过使用Accept Features标头，远程变量选择算法有时可以代表用户代理确定特征谓词的真值。例如，使用标题
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
paper = A4, paper!="A2", x-version=104, *
Accept-Features: blex, !blebber, colordepth={5}, !screenwidth,
paper = A4, paper!="A2", x-version=104, *
the algorithm can determine that the following predicates are true:
该算法可以确定以下谓词为真：
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth,
paper=A4, colordepth=[4-6]
blex, colordepth=[4-], colordepth!=6, colordepth, !screenwidth,
paper=A4, colordepth=[4-6]
and that the following predicates are false:
并且以下谓词为false：
!blex, blebber, colordepth=6, colordepth=foo, !colordepth, screenwidth, screenwidth=640, screenwidth!=640,
!气泡，气泡，颜色深度=6，颜色深度=foo！颜色深度，屏幕宽度，屏幕宽度=640，屏幕宽度=640,
but the truth value of the following predicates cannot be determined:
但无法确定以下谓词的真值：
UA-media=stationary, UA-media!=screen, paper!=a0,
x-version=[100-300], x-version=[200-300], x-version=99,
UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
UA-media=stationary, UA-media!=screen, paper!=a0,
x-version=[100-300], x-version=[200-300], x-version=99,
UA-media=screen, paper=A0, paper=a4, x-version=[100-199], wuxta
The Alternates response header is used to convey the list of variants bound to a negotiable resource. This list can also include directives for any content negotiation process. If a response from a transparently negotiable resource includes an Alternates header, this header MUST contain the complete variant list bound to the negotiable resource. Responses from resources which do not support transparent content negotiation MAY also use Alternates headers.
Alternates响应头用于传递绑定到可协商资源的变量列表。此列表还可以包括任何内容协商过程的指令。如果来自透明可协商资源的响应包含Alternates标头，则此标头必须包含绑定到可协商资源的完整变体列表。来自不支持透明内容协商的资源的响应也可以使用备选标题。
Alternates = "Alternates" ":" variant-list
Alternates=“Alternates”“：”变体列表
variant-list = 1#( variant-description | fallback-variant | list-directive )
变量列表=1#（变量描述|回退变量|列表指令）
fallback-variant = "{" <"> URI <"> "}"
fallback-variant = "{" <"> URI <"> "}"
list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )
list-directive = ( "proxy-rvsa" "=" <"> 0#rvsa-version <"> )
| extension-list-directive
|扩展列表指令
extension-list-directive = token [ "=" ( token | quoted-string ) ]
扩展列表指令=令牌[“=”（令牌|带引号的字符串）]
An example is
例如
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}},
proxy-rvsa="1.0, 2.5"
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}},
proxy-rvsa="1.0, 2.5"
Any relative URI specified in a variant-description or fallback-variant field is relative to the request-URI. Only one fallback-variant field may be present. If the variant selection algorithm of the user agent finds that all described variants are unacceptable, then it SHOULD choose the fallback variant, if present, as the best variant. If the user agent computes the overall quality values of the described variants, and finds that several variants share the highest value, then the first variant with this value in the list SHOULD be chosen as the best variant.
变量描述或回退变量字段中指定的任何相对URI都是相对于请求URI的。只能存在一个回退变量字段。如果用户代理的变体选择算法发现所有描述的变体都是不可接受的，那么它应该选择回退变体（如果存在）作为最佳变体。如果用户代理计算所述变体的总体质量值，并发现多个变体共享最高值，则应选择列表中具有此值的第一个变体作为最佳变体。
The proxy-rvsa directive restricts the use of remote variant selection algorithms by proxies. If present, a proxy MUST ONLY use algorithms which have one of the version numbers listed, or have the same major version number and a higher minor version number as one of the versions listed. Any restrictions set by proxy-rvsa come on top of the restrictions set by the user agent in the Negotiate request header. The directive proxy-rvsa="" will disable variant selection by proxies entirely. Clients SHOULD ignore all extension-list-directives they do not understand.
proxy rvsa指令限制代理使用远程变量选择算法。如果存在代理，则代理必须仅使用列出其中一个版本号的算法，或使用与列出的其中一个版本相同的主版本号和更高的次版本号的算法。代理rvsa设置的任何限制都位于用户代理在协商请求标头中设置的限制之上。指令proxy rvsa=“”将完全禁用代理选择变量。客户端应该忽略所有他们不理解的扩展列表指令。
A variant list may contain multiple differing descriptions of the same variant. This can be convenient if the variant uses conditional rendering constructs, or if the variant resource returns multiple representations using a multipart media type.
变量列表可能包含同一变量的多个不同描述。如果变量使用条件呈现构造，或者如果变量资源使用多部分媒体类型返回多个表示，则这会很方便。
The Negotiate request header can contain directives for any content negotiation process initiated by the request.
协商请求头可以包含请求发起的任何内容协商过程的指令。
Negotiate = "Negotiate" ":" 1#negotiate-directive
Negotiate = "Negotiate" ":" 1#negotiate-directive
negotiate-directive = "trans" | "vlist" | "guess-small"
协商指令=“trans”|“vlist”|“猜小”
| rvsa-version
| "*"
| negotiate-extension
| rvsa-version
| "*"
| negotiate-extension
negotiate-extension = token [ "=" token ]
协商扩展=令牌[“=”令牌]
Examples are
例如
Negotiate: 1.0, 2.5 Negotiate: *
协商：1.0，2.5协商：*
The negotiate directives have the following meaning
协商指令具有以下含义
"trans" The user agent supports transparent content negotiation for the current request.
“trans”用户代理支持当前请求的透明内容协商。
"vlist" The user agent requests that any transparently negotiated response for the current request includes an Alternates header with the variant list bound to the negotiable resource. Implies "trans".
“vlist”用户代理请求当前请求的任何透明协商响应都包含一个备选标头，其中变量列表绑定到可协商资源。表示“trans”。
"guess-small" The user agent allows origin servers to run a custom algorithm which guesses the best variant for the request, and to return this variant in a choice response, if the resulting choice response is smaller than or not much larger than a list response. The definition of `not much larger' is left to origin server heuristics. Implies "vlist" and "trans".
“guess small”用户代理允许源服务器运行自定义算法，该算法猜测请求的最佳变量，并在选择响应中返回该变量（如果生成的选择响应小于或不大于列表响应）。“大不了多少”的定义留给原始服务器启发法。表示“vlist”和“trans”。
rvsa-version The user agent allows origin servers and proxies to run the remote variant selection algorithm with the indicated version number, or with the same major version number and a higher minor version number. If the algorithm has sufficient information to choose a best, neighboring variant, the origin server or proxy MAY return a choice response with this variant. Implies "trans".
rvsa版本用户代理允许源服务器和代理使用指定的版本号或相同的主版本号和更高的次版本号运行远程变量选择算法。如果算法有足够的信息来选择最佳的相邻变量，则源服务器或代理可能会返回带有此变量的选择响应。表示“trans”。
"*" The user agent allows origin servers and proxies to run any remote variant selection algorithm. The origin server may even run algorithms which have not been standardized. If the algorithm has sufficient information to choose a best, neighboring variant, the origin server or proxy MAY return a choice response with this variant. Implies "trans".
“*”用户代理允许源服务器和代理运行任何远程变量选择算法。源服务器甚至可能运行尚未标准化的算法。如果算法有足够的信息来选择最佳的相邻变量，则源服务器或代理可能会返回带有此变量的选择响应。表示“trans”。
Servers SHOULD ignore all negotiate-directives they do not understand. If the Negotiate header allows a choice between multiple remote variant selection algorithms which are all supported by the server, the server SHOULD use some internal precedence heuristics to select the best algorithm.
服务器应该忽略所有他们不理解的协商指令。如果协商头允许在服务器支持的多个远程变量选择算法之间进行选择，则服务器应使用一些内部优先启发式来选择最佳算法。
The TCN response header is used by a server to signal that the resource is transparently negotiated.
服务器使用TCN响应头来表示资源是透明协商的。
TCN = "TCN" ":" #( response-type | server-side-override-directive | tcn-extension )
TCN=“TCN”“：”#（响应类型|服务器端覆盖指令| TCN扩展）
response-type = "list" | "choice" | "adhoc"
response-type = "list" | "choice" | "adhoc"
server-side-override-directive = "re-choose" | "keep"
server-side-override-directive = "re-choose" | "keep"
tcn-extension = token [ "=" ( token | quoted-string ) ]
tcn扩展名=令牌[“=”（令牌|带引号的字符串）]
If the resource is not transparently negotiated, a TCN header MUST NOT be included in any response. If the resource is transparently negotiated, a TCN header, which includes the response-type value of the response, MUST be included in every response with a 2xx status code or any 3xx status code, except 304, in which it MAY be included. A TCN header MAY also be included, without a response-type value, in other responses from transparently negotiated resources.
如果资源不是透明协商的，则任何响应中都不得包含TCN头。如果资源是透明协商的，则TCN报头（包括响应的响应类型值）必须包含在每个响应中，并带有2xx状态代码或任何3xx状态代码，304除外，其中可能包含TCN报头。TCN报头也可以包括在来自透明协商资源的其他响应中，而不包括响应类型值。
A server-side override directive MUST be included if the origin server performed a server-side override when choosing the response. If the directive is "re-choose", the server MUST include an Alternates header with the variant bound to the negotiable resource in the response, and user agent SHOULD use its internal variant selection algorithm to choose, retrieve, and display the best variant from this list. If the directive is "keep" the user agent SHOULD NOT renegotiate on the response, but display it directly, or act on it directly if it is a redirection response.
如果源服务器在选择响应时执行了服务器端覆盖，则必须包含服务器端覆盖指令。如果指令为“re choose”，服务器必须在响应中包含一个带有绑定到可协商资源的变量的Alternates标头，并且用户代理应使用其内部变量选择算法从该列表中选择、检索和显示最佳变量。如果指令为“keep”，则用户代理不应就响应重新协商，而应直接显示该响应，如果是重定向响应，则直接对其进行操作。
Clients SHOULD ignore all tcn-extensions they do not understand.
客户端应该忽略他们不理解的所有tcn扩展。
The Variant-Vary response header can be used in a choice response to record any vary information which applies to the variant data (the entity body combined with some of the entity headers) contained in the response, rather than to the response as a whole.
Variant Vary响应头可用于选择响应中，以记录应用于响应中包含的变量数据（实体主体与一些实体头组合）而不是整个响应的任何Vary信息。
Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name )
Variant-Vary = "Variant-Vary" ":" ( "*" | 1#field-name )
Use of the Variant-Vary header is discussed in section 10.2.
第10.2节讨论了变体VARIE标题的使用。
9 Cache validators
9缓存验证器
To allow for correct and efficient caching and revalidation of negotiated responses, this specification extends the caching model of HTTP/1.1 [1] in various ways.
为了允许正确有效地缓存和重新验证协商响应，本规范以各种方式扩展了HTTP/1.1[1]的缓存模型。
This specification does not introduce a `variant-list-max-age' directive which explicitly bounds the freshness lifetime of a cached variant list, like the `max-age' Cache-Control directive bounds the freshness lifetime of a cached response. However, this specification does ensure that a variant list which is sent at a time T by the origin server will never be re-used without revalidation by semantically transparent caches after the time T+M. This M is the maximum of all freshness lifetimes assigned (using max-age directives or Expires headers) by the origin server to
本规范不引入“variant list max age”指令，该指令明确限制缓存变量列表的新鲜度生存期，就像“max age”缓存控制指令限制缓存响应的新鲜度生存期一样。但是，本规范确实确保源服务器在时间T发送的变体列表在时间T+M之后，如果没有语义透明缓存的重新验证，将永远不会被重新使用。此M是源服务器分配给的所有新鲜度生存期（使用max age指令或Expires头）的最大值
a. the responses from the negotiable resource itself, and
a. 可协商资源本身的响应，以及
b. the responses from its neighboring variant resources
b. 来自邻近变异资源的响应
If no freshness lifetimes are assigned by the origin server, M is the maximum of the freshness lifetimes which were heuristically assigned by all caches which can re-use the variant list.
如果源服务器未分配新鲜度生存期，则M是可重复使用变体列表的所有缓存试探性分配的新鲜度生存期的最大值。
A variant list validator is an opaque value which acts as the cache validator of a variant list bound to a negotiable resource.
变量列表验证器是一个不透明的值，它充当绑定到可协商资源的变量列表的缓存验证器。
variant-list-validator = <quoted-string not containing any ";">
variant-list-validator = <quoted-string not containing any ";">
If two responses contain the same variant list validator, a cache can treat the Alternates headers in these responses as equivalent (though the headers themselves need not be identical).
如果两个响应包含相同的变体列表验证器，缓存可以将这些响应中的Alternates标头视为等效的（尽管标头本身不必相同）。
A structured entity tag consists of a normal entity tag of which the opaque string is extended with a semicolon followed by the text (without the surrounding quotes) of a variant list validator:
结构化实体标记由普通实体标记组成，其中不透明字符串用分号扩展，后跟变体列表验证程序的文本（不带引号）：
normal | variant list | structured
entity tag | validator | entity tag
-------------+----------------+-----------------
"etag" | "vlv" | "etag;vlv"
W/"etag" | "vlv" | W/"etag;vlv"
normal | variant list | structured
entity tag | validator | entity tag
-------------+----------------+-----------------
"etag" | "vlv" | "etag;vlv"
W/"etag" | "vlv" | W/"etag;vlv"
Note that a structured entity tag is itself also an entity tag. The structured nature of the tag allows caching proxies capable of transparent content negotiation to perform some optimizations defined in section 10. When not performing such optimizations, a structured tag SHOULD be treated as a single opaque value, according to the general rules in HTTP/1.1. Examples of structured entity tags are:
请注意，结构化实体标记本身也是一个实体标记。标记的结构化特性允许能够进行透明内容协商的缓存代理执行第10节中定义的一些优化。当不执行此类优化时，根据HTTP/1.1中的一般规则，结构化标记应被视为单个不透明值。结构化实体标记的示例包括：
"xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234"
"xyzzy;1234" W/"xyzzy;1234" "gonkxxxx;1234" "a;b;c;;1234"
In the last example, the normal entity tag is "a;b;c;" and the variant list validator is "1234".
在最后一个示例中，普通实体标记是“a；b；c；”，变量列表验证器是“1234”。
If a transparently negotiated response includes an entity tag, it MUST be a structured entity tag. The variant list validator in the structured tag MUST act as a validator for the variant list contained in the Alternates header. The normal entity tag in the structured tag MUST act as a validator of the entity body in the response and of all entity headers except Alternates.
如果透明协商响应包含实体标记，则它必须是结构化实体标记。结构化标记中的变量列表验证器必须充当Alternates标头中包含的变量列表的验证器。结构化标记中的普通实体标记必须充当响应中实体主体和所有实体头（备用项除外）的验证器。
To allow for correct revalidation of transparently negotiated responses by clients, origin servers SHOULD generate all normal entity tags for the neighboring variant resources of the negotiable resource in such a way that
为了允许客户端正确地重新验证透明协商的响应，源服务器应为可协商资源的相邻变体资源生成所有正常实体标记，其方式如下：
1. the same tag is never used by two different variants, unless this tag labels exactly the same entity on all occasions,
1. 两个不同的变体永远不会使用相同的标记，除非此标记在所有情况下都标记完全相同的实体，
2. if one normal tag "X" is a prefix of another normal tag "XY", then "Y" must never be a semicolon followed by a variant list validator.
2. 如果一个普通标记“X”是另一个普通标记“XY”的前缀，则“Y”决不能是后跟变体列表验证器的分号。
10 Content negotiation responses
10内容谈判响应
If a request on a transparently negotiated resource yields a response with a 2xx status code or any 3xx status code except 304, this response MUST always be either a list response, a choice response, or an adhoc response. These responses MUST always include a TCN header which specifies their type. Transparently negotiated responses with other status codes MAY also include a TCN header.
如果对透明协商资源的请求产生带有2xx状态代码或除304之外的任何3xx状态代码的响应，则该响应必须始终是列表响应、选择响应或特殊响应。这些响应必须始终包含指定其类型的TCN标头。与其他状态代码透明协商的响应也可以包括TCN报头。
The conditions under which the different content negotiation responses may be sent are defined in section 12.1 for origin servers and in section 13 for proxies.
第12.1节为源服务器定义了发送不同内容协商响应的条件，第13节为代理服务器定义了不同内容协商响应的条件。
After having constructed a list, choice, or adhoc response, a server MAY process any If-No-Match or If-Range headers in the request message and shorten the response to a 304 (Not Modified) or 206 (Partial Content) response, following the rules in the HTTP/1.1 specification [1]. In this case, the entity tag of the shortened response will identify it indirectly as a list, choice, or adhoc response.
在构造了列表、选项或临时响应之后，服务器可以处理请求消息中的任何If-No-Match或If-Range头，并按照HTTP/1.1规范[1]中的规则将响应缩短为304（未修改）或206（部分内容）响应。在这种情况下，缩短响应的实体标记将间接地将其标识为列表、选择或特殊响应。
A list response returns the variant list of the negotiable resource, but no variant data. It can be generated when the server does not want to, or is not allowed to, return a particular best variant for the request. If the user agent supports transparent content negotiation, the list response will cause it to select a best variant and retrieve it.
列表响应返回可协商资源的变量列表，但不返回变量数据。当服务器不想或不允许为请求返回特定的最佳变体时，可以生成该请求。如果用户代理支持透明内容协商，列表响应将导致它选择最佳变体并检索它。
A list response MUST contain (besides the normal headers required by HTTP) a TCN header which specifies the "list" response-type, the Alternates header bound to the negotiable resource, a Vary header and (unless it was a HEAD request) an entity body which allows the user to manually select the best variant.
列表响应必须包含（除了HTTP要求的正常头之外）一个TCN头，该头指定“列表”响应类型、绑定到可协商资源的交替头、一个Vary头和一个允许用户手动选择最佳变体的实体体（除非是头请求）。
An example of a list response is
列表响应的一个示例是
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
HTTP/1.1 300 Multiple Choices
Date: Tue, 11 Jun 1996 20:02:21 GMT
TCN: list
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Vary: negotiate, accept, accept-language
ETag: "blah;1234"
Cache-control: max-age=86400
Content-Type: text/html
Content-Length: 227
<h2>Multiple Choices:</h2>
<ul>
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
<h2>Multiple Choices:</h2>
<ul>
<li><a href=paper.1>HTML, English version</a>
<li><a href=paper.2>HTML, French version</a>
<li><a href=paper.3>Postscript, English version</a>
</ul>
Note: A list response can have any status code, but the 300 (Multiple Choices) code is the most appropriate one for HTTP/1.1 clients. Some existing versions of HTTP/1.0 clients are known to silently ignore 300 responses, instead of handling them according to the HTTP/1.0 specification [2]. Servers should therefore be careful in sending 300 responses to non-negotiating HTTP/1.0 user agents, and in making these responses cacheable. The 200 (OK) status code can be used instead.
注意：列表响应可以有任何状态代码，但300（多选）代码最适合HTTP/1.1客户端。已知一些现有版本的HTTP/1.0客户端会默默地忽略300个响应，而不是根据HTTP/1.0规范处理它们[2]。因此，服务器在向非协商HTTP/1.0用户代理发送300个响应以及使这些响应可缓存时应小心。可以改用200（正常）状态代码。
The Vary header in the response SHOULD ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be
响应中的Vary头应确保通过普通HTTP/1.1缓存代理正确处理。此标题可以是
Vary: *
变化：*
or a more elaborate header; see section 10.6.1.
或者一个更精致的标题；见第10.6.1节。
Only the origin server may construct list responses. Depending on the status code, a list response is cacheable unless indicated otherwise.
只有源服务器可以构造列表响应。根据状态代码，列表响应是可缓存的，除非另有说明。
According to the HTTP/1.1 specification [1], a user agent which does not support transparent content negotiation will, when receiving a list response with the 300 status code, display the entity body included in the response. If the response contains a Location header, however, the user agent MAY automatically redirect to this location.
根据HTTP/1.1规范[1]，不支持透明内容协商的用户代理在接收到状态代码为300的列表响应时，将显示响应中包含的实体体。但是，如果响应包含位置标头，则用户代理可以自动重定向到此位置。
The handling of list responses by clients supporting transparent content negotiation is described in sections 11.1 and 13.
第11.1节和第13节描述了支持透明内容协商的客户端对列表响应的处理。
A choice response returns a representation of the best variant for the request, and may also return the variant list of the negotiable resource. It can be generated when the server has sufficient information to be able to choose the best variant on behalf the user agent, but may only be generated if this best variant is a neighboring variant. For request from user agents which do not support transparent content negotiation, a server may always generate a choice response, provided that the variant returned is a neighboring variant. The variant returned in a choice response need not necessarily be listed in the variant list bound to the negotiable resource.
选择响应返回请求的最佳变体的表示，还可以返回可协商资源的变体列表。当服务器有足够的信息能够代表用户代理选择最佳变体时，可以生成该变量，但只有当该最佳变体是相邻变体时，才可以生成该变量。对于来自不支持透明内容协商的用户代理的请求，服务器可能始终生成选择响应，前提是返回的变量是相邻的变量。选择响应中返回的变量不一定要列在绑定到可协商资源的变量列表中。
A choice response merges a normal HTTP response from the chosen variant, a TCN header which specifies the "choice" response-type, and a Content-Location header giving the location of the variant. Depending on the status code, a choice response is cacheable unless indicated otherwise.
choice响应合并来自所选变体的正常HTTP响应、指定“choice”响应类型的TCN头和给出变体位置的内容位置头。根据状态代码，选择响应可缓存，除非另有说明。
Origin servers and proxy caches MUST construct choice responses with the following algorithm (or any other algorithm which gives equal end results for the client).
源服务器和代理缓存必须使用以下算法（或为客户端提供相同最终结果的任何其他算法）构造选择响应。
In this algorithm, `the current Alternates header' refers to the Alternates header containing the variant list which was used to choose the best variant, and `the current variant list validator' refers to the validator of this list. Section 10.4 specifies how these two items can be obtained by a proxy cache.
在该算法中，`current Alternates header'指包含用于选择最佳变体的变体列表的Alternates header，`current variant list validator'指该列表的验证器。第10.4节规定了如何通过代理缓存获取这两个项。
The algorithm consists of four steps.
该算法由四个步骤组成。
1. Construct a HTTP request message on the best variant resource by rewriting the request-URI and Host header (if appropriate) of the received request message on the negotiable resource.
1. 通过重写可协商资源上收到的请求消息的请求URI和主机头（如果合适），在最佳变体资源上构造HTTP请求消息。
2. Generate a valid HTTP response message, but not one with the 304 (Not Modified) code, for the request message constructed in step 1.
2. 为步骤1中构造的请求消息生成有效的HTTP响应消息，但不生成包含304（未修改）代码的响应消息。
In a proxy cache, the response can be obtained from cache memory, or by passing the constructed HTTP request towards the origin server. If the request is passed on, the proxy MAY add, modify, or delete If-None-Match and If-Range headers to optimize the transaction with the upstream server.
在代理缓存中，可以从缓存中获取响应，或者通过将构造的HTTP请求传递给源服务器来获取响应。如果请求被传递，则代理可以添加、修改或删除If-None-Match和If-Range头，以优化与上游服务器的事务。
Note: the proxy should be careful not to add entity tags of non-neighboring variants to If-* (conditional) headers of the request, as there are no global uniqueness requirements for these tags.
注意：代理应该注意不要将非相邻变量的实体标记添加到请求的If-*（条件）头中，因为这些标记没有全局唯一性要求。
3. Only in origin servers: check for an origin server configuration error. If the HTTP response message generated in step 2 contains a TCN header, then the best variant resource is not a proper end point in the transparent negotiation process, and a 506 (Variant Also Negotiates) error response message SHOULD be generated instead of going to step 4.
3. 仅在源服务器中：检查源服务器配置错误。如果在步骤2中生成的HTTP响应消息包含TCN头，则最佳变体资源不是透明协商过程中的适当端点，并且应生成506（变体也协商）错误响应消息，而不是转到步骤4。
4. Add a number of headers to the HTTP response message generated in step 2.
4. 向步骤2中生成的HTTP响应消息添加多个标头。
a. Add a TCN header which specifies the "choice" response-type.
a. 添加指定“选择”响应类型的TCN标头。
b. Add a Content-Location header giving the location of the chosen variant. Delete any Content-Location header which was already present.
b. 添加内容位置标题，给出所选变体的位置。删除已存在的任何内容位置标题。
Note: According to the HTTP/1.1 specification [1], if the Content-Location header contains a relative URI, this URI is relative to the URI in the Content-Base header, if present, and relative to the request-URI if no Content-Base header is present.
注意：根据HTTP/1.1规范[1]，如果内容位置标头包含相对URI，则此URI相对于内容基标头（如果存在）中的URI，如果不存在内容基标头，则相对于请求URI。
c. If any Vary headers are present in the response message from step 2, add, for every Vary header, a Variant-Vary header with a copy of the contents of this Vary header.
c. 如果步骤2的响应消息中存在任何VARIVE标头，则为每个VARIVE标头添加一个Variant VARIE标头，其中包含该VARIE标头内容的副本。
d. Delete any Alternates headers which are present in in the response. Now, the current Alternates header MUST be added if this is required by the Negotiate request header, or if the server returns "re-choose" in the TCN response header. Otherwise, the current Alternates header MAY be added.
d. 删除响应中存在的任何备选标题。现在，如果协商请求报头需要，或者如果服务器在TCN响应报头中返回“re choose”，则必须添加current Alternates报头。否则，可能会添加当前的Alternates标头。
Note: It is usually a good strategy to always add the current Alternates header, unless it is very large compared to the rest of the response.
注意：总是添加当前Alternates头通常是一个好策略，除非它与响应的其余部分相比非常大。
e. Add a Vary header to ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be
e. 添加Vary头以确保通过普通HTTP/1.1缓存代理正确处理。此标题可以是
Vary: * or a more elaborate header, see section 10.6.
更改：*或更详细的标题，请参见第10.6节。
f. To ensure compatibility with HTTP/1.0 caching proxies which do not recognize the Vary header, an Expires header with a date in the past MAY be added. See section 10.7 for more information.
f. 为确保与不识别Vary头的HTTP/1.0缓存代理兼容，可以添加日期在过去的Expires头。更多信息请参见第10.7节。
g. If an ETag header is present in the response message from step 2, then extend the entity tag in that header with the current variant list validator, as specified in section 9.2.
g. 如果步骤2的响应消息中存在ETag头，则使用当前变体列表验证程序扩展该头中的实体标记，如第9.2节所述。
Note: Step g. is required even if the variant list itself is not added in step d.
注：步骤g。即使在步骤d中未添加变体列表本身，也需要。
h. Only in proxy caches: set the Age header of the response to
h. 仅在代理缓存中：将响应的年龄标头设置为
max( variant_age , alternates_age )
最大值（变量年龄、替代年龄）
where variant_age is the age of the variant response obtained in step 2, calculated according to the rules in the HTTP/1.1 specification [1], and alternates_age is the age of the Alternates header added in step d, calculated according to the rules in section 10.4.
其中，variant_age是根据HTTP/1.1规范[1]中的规则计算的在步骤2中获得的变体响应的时间，alternates_age是根据第10.4节中的规则计算的在步骤d中添加的alternates报头的时间。
Note that a server can shorten the response produced by the above algorithm to a 304 (Not Modified) response if an If-None-Match header in the original request allows it. If this is the case, an implementation of the above algorithm can avoid the unnecessary internal construction of full response message in step 2, it need only construct the parts which end up in the final 304 response. A proxy cache which implements this optimization can sometimes generate a legal 304 response even if it has not cached the variant data itself.
注意，如果原始请求中的if None匹配头允许，服务器可以将上述算法生成的响应缩短为304（未修改）响应。如果是这种情况，上述算法的实现可以避免步骤2中不必要的完整响应消息的内部构造，它只需要构造最终304响应中的部分。实现此优化的代理缓存有时可以生成合法的响应，即使它没有缓存变量数据本身。
An example of a choice response is:
选择响应的一个示例是：
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.1
Alternates: {"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript}
{language en}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
<title>A paper about ....
<title>A paper about ....
An adhoc response can be sent by an origin server as an extreme measure, to achieve compatibility with a non-negotiating or buggy client if this compatibility cannot be achieved by sending a list or choice response. There are very little requirements on the contents of an adhoc response. An adhoc response MUST have a TCN header which specifies the "adhoc" response-type, and a Vary header if the response is cacheable. It MAY contain the Alternates header bound to the negotiable resource.
如果无法通过发送列表或选择响应来实现兼容性，则源服务器可以发送临时响应作为一种极端措施，以实现与非协商或错误客户端的兼容性。对临时响应的内容要求很少。临时响应必须有一个指定“临时”响应类型的TCN头，如果响应是可缓存的，则必须有一个Vary头。它可能包含绑定到可协商资源的Alternates头。
Any Vary header in the response SHOULD ensure correct handling by plain HTTP/1.1 caching proxies. This header can either be
响应中的任何Vary头都应确保通过普通HTTP/1.1缓存代理进行正确处理。此标题可以是
Vary: *
变化：*
or a more elaborate header, see section 10.6.1. Depending on the status code, an adhoc response is cacheable unless indicated otherwise.
或更详细的标题，见第10.6.1节。根据状态代码，除非另有说明，否则临时响应是可缓存的。
As an example of the use of an adhoc response, suppose that the variant resource "redirect-to-blah" yields redirection (302) responses. A choice response with this variant could look as follows:
作为使用临时响应的示例，假设变体资源“重定向到blah”产生重定向（302）响应。使用此变体的选择响应可能如下所示：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:02:28 GMT
TCN: choice
Content-location: redirect-to-blah
Location: http://blah.org/
Content-Type: text/html
Content-Length: 62
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:02:28 GMT
TCN: choice
Content-location: redirect-to-blah
Location: http://blah.org/
Content-Type: text/html
Content-Length: 62
This document is available <a href=http://blah.org/>here</a>.
此文档可用<a href=http://blah.org/>这里</a>。
Suppose that the server knows that the receiving user agent has a bug, which causes it to crash on responses which contain both a Content-Location and a Location header. The server could then work around this bug by performing a server-side override and sending the following adhoc response instead:
假设服务器知道接收用户代理有一个bug，导致它在包含内容位置和位置头的响应上崩溃。然后，服务器可以通过执行服务器端覆盖并发送以下临时响应来解决此错误：
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:02:28 GMT
TCN: adhoc, keep
Location: http://blah.org/
Content-Type: text/html
Content-Length: 62
HTTP/1.1 302 Moved Temporarily
Date: Tue, 11 Jun 1996 20:02:28 GMT
TCN: adhoc, keep
Location: http://blah.org/
Content-Type: text/html
Content-Length: 62
This document is available <a href=http://blah.org/>here</a>.
此文档可用<a href=http://blah.org/>这里</a>。
If a proxy cache has available a negotiated response which is cacheable, fresh, and has ETag and Alternates headers, then it MAY extract the Alternates header and associated variant list validator from the response, and reuse them (without unnecessary delay) to
如果代理缓存具有可缓存、新鲜且具有ETag和Alternates标头的协商响应，则它可以从响应中提取Alternates标头和关联的变体列表验证器，并重用它们（没有不必要的延迟）以
negotiate on behalf of the user agent (section 13) or to construct a choice response (section 10.2). The age of the extracted Alternates header is the age of the response from which it is extracted, calculated according to the rules in the HTTP/1.1 specification [1].
代表用户代理进行协商（第13节）或构建选择响应（第10.2节）。提取的Alternates头的年龄是从中提取的响应的年龄，根据HTTP/1.1规范中的规则计算[1]。
If a proxy receives a choice response, it MAY extract and cache the normal HTTP response contained therein. The normal response can be extracted by taking a copy of the choice response and then deleting any Content-Location, Alternates, and Vary headers, renaming any Variant-Vary headers to Vary headers, and shortening the structured entity tag in any ETag header to a normal entity tag.
如果代理收到选择响应，它可以提取并缓存其中包含的正常HTTP响应。可以通过以下方式提取正常响应：获取choice响应的副本，然后删除任何内容位置、替换和更改标题，重命名任何Variant Varie标题以更改标题，并将任何ETag标题中的结构化实体标记缩短为正常实体标记。
This normal response MAY be cached (as a HTTP response to the variant request as constructed in step 1. of section 10.2) and reused to answer future direct requests on the variant resource, according to the rules in the HTTP/1.1 specification [1].
根据HTTP/1.1规范[1]中的规则，可以缓存该正常响应（作为对在第10.2节步骤1中构造的变量请求的HTTP响应），并重新使用该响应来响应变量资源上的未来直接请求。
Note: The caching of extracted responses can decrease the upstream bandwidth usage with up to a factor 2, because two independent HTTP/1.1 cache entries, one associated with the negotiable resource URI and one with the variant URI, are created in the same transaction. Without this optimization, both HTTP/1.1 cache entries can only be created by transmitting the variant data twice.
注意：缓存提取的响应可以将上游带宽使用率降低到2倍，因为在同一事务中创建了两个独立的HTTP/1.1缓存项，一个与可协商资源URI关联，另一个与变量URI关联。如果没有这种优化，两个HTTP/1.1缓存项只能通过传输两次变量数据来创建。
For security reasons (see section 14.2), an extracted normal response MUST NEVER be cached if belongs to a non-neighboring variant resource. If the choice response claims to contain data for a non-neighboring variant resource, the proxy SHOULD reject the choice response as a probable spoofing attempt.
出于安全原因（请参见第14.2节），如果提取的正常响应属于非相邻的变体资源，则不得缓存该响应。如果选择响应声称包含非相邻变体资源的数据，则代理应拒绝选择响应，因为这可能是欺骗企图。
If a HTTP/1.1 [1] server can generate varying responses for a request on some resource, then the server MUST include a Vary header in these responses if they are cacheable. This Vary header is a signal to HTTP/1.1 caches that something special is going on. It prevents the caches from returning the currently chosen response for every future request on the resource.
如果HTTP/1.1[1]服务器可以为某些资源上的请求生成不同的响应，那么如果这些响应是可缓存的，则服务器必须在这些响应中包含Vary头。这个Vary头是HTTP/1.1缓存的一个信号，表示正在发生一些特殊的事情。它防止缓存为资源上的每个未来请求返回当前选择的响应。
Servers engaging in transparent content negotiation will generate varying responses. Therefore, cacheable list, choice, and adhoc responses MUST always include a Vary header.
参与透明内容协商的服务器将生成不同的响应。因此，可缓存列表、选项和临时响应必须始终包含一个Vary头。
The most simple Vary header which can be included is
可以包括的最简单的Vary标题是
Vary: *
变化：*
This header leaves the way in which the response is selected by the server completely unspecified.
此标头完全未指定服务器选择响应的方式。
A more elaborate Vary header MAY be used to allow for certain optimizations in HTTP/1.1 caches which do not have specific optimizations for transparent content negotiation, but which do cache multiple variant responses for one resource. Such a more elaborate Vary header lists all request headers which can be used by the server when selecting a response for a request on the resource.
可以使用更详细的Vary头来允许HTTP/1.1缓存中的某些优化，这些缓存没有针对透明内容协商的特定优化，但可以缓存一个资源的多个变量响应。这样一个更详细的Vary头列出了服务器在为资源上的请求选择响应时可以使用的所有请求头。
Origin servers can construct a more elaborate Vary header in the following way. First, start with the header
源服务器可以通过以下方式构造更复杂的Vary头。首先，从标题开始
Vary: negotiate
改变：谈判
`negotiate' is always included because servers use the information in the Negotiate header when choosing between a list, choice, or adhoc response.
`“协商”始终包含在内，因为服务器在列表、选项或临时响应之间进行选择时使用协商标头中的信息。
Then, if any of the following attributes is present in any variant description in the Alternates header, add the corresponding header name to the Vary header
然后，如果Alternates标头中的任何变体描述中存在以下任何属性，请将相应的标头名称添加到Variable标头
attribute | header name to add
-----------+---------------------
type | accept
charset | accept-charset
language | accept-language
features | accept-features
attribute | header name to add
-----------+---------------------
type | accept
charset | accept-charset
language | accept-language
features | accept-features
The Vary header constructed in this way specifies the response variation which can be caused by the use of a variant selection algorithm in proxies. If the origin server will in some cases, for example if contacted by a non-negotiating user agent, use a custom negotiation algorithm which takes additional headers into account, these names of these headers SHOULD also be added to the Vary header.
以这种方式构造的Vary头指定了在代理中使用变量选择算法可能导致的响应变化。如果源服务器在某些情况下（例如，如果由非协商用户代理联系）将使用考虑其他标头的自定义协商算法，则这些标头的名称也应添加到Vary标头中。
A proxy cache cannot construct an elaborate vary header using the method above, because this method requires exact knowledge of any custom algorithms present in the origin server. However, when extracting an Alternates header from a response (section 10.4) caches MAY also extract the Vary header in the response, and reuse it along with the Alternates header. A clean Vary header can however only be extracted if the variant does not vary itself, i.e. if a Variant-Vary header is absent.
代理缓存无法使用上述方法构造复杂的vary头，因为此方法需要精确了解原始服务器中存在的任何自定义算法。但是，当从响应中提取Alternates标头时（第10.4节），缓存也可以提取响应中的Variable标头，并将其与Alternates标头一起重用。但是，只有在变体本身没有变化的情况下（即，如果没有变体变体标头），才能提取干净的变体标头。
To ensure compatibility with HTTP/1.0 caching proxies which do not recognize the Vary header, an Expires header with a date in the past can be added to the response, for example
为了确保与HTTP/1.0缓存代理（不识别Vary头）的兼容性，例如，可以在响应中添加日期为过去的Expires头
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Expires: Thu, 01 Jan 1980 00:00:00 GMT
If this is done by an origin server, the server SHOULD usually also include a Cache-Control header for the benefit of HTTP/1.1 caches, for example
如果这是由源服务器完成的，那么服务器通常还应该包括一个缓存控制头，以便于HTTP/1.1缓存
Cache-Control: max-age=604800
缓存控制：最大年龄=604800
which overrides the freshness lifetime of zero seconds specified by the included Expires header.
它覆盖由包含的Expires标头指定的零秒新鲜度生存期。
Note: This specification only claims downwards compatibility with the HTTP/1.0 proxy caches which implement the HTTP/1.0 specification [2]. Some legacy proxy caches which return the HTTP/1.0 protocol version number do not honor the HTTP/1.0 Expires header as specified in [2]. Methods for achieving compatibility with such proxy caches are beyond the scope of this specification.
注意：本规范仅要求与实现HTTP/1.0规范的HTTP/1.0代理缓存向下兼容[2]。某些返回HTTP/1.0协议版本号的旧版代理缓存不支持[2]中指定的HTTP/1.0 Expires标头。实现与此类代理缓存的兼容性的方法超出了本规范的范围。
Negotiation on the content encoding of a response is orthogonal to transparent content negotiation. The rules for when a content encoding may be applied are the same as in HTTP/1.1: servers MAY content-encode responses that are the result of transparent content negotiation whenever an Accept-Encoding header in the request allows it. When negotiating on the content encoding of a cacheable response, servers MUST add the accept-encoding header name to the Vary header of the response, or add `Vary: *'.
响应的内容编码协商与透明内容协商正交。何时可以应用内容编码的规则与HTTP/1.1中的规则相同：只要请求中的Accept encoding标头允许，服务器就可以对作为透明内容协商结果的响应进行内容编码。在协商可缓存响应的内容编码时，服务器必须将接受编码头名称添加到响应的Vary头，或添加“Vary:*”。
Servers SHOULD always be able to provide unencoded versions of every transparently negotiated response. This means in particular that every variant in the variant list SHOULD at least be available in an unencoded form.
服务器应始终能够提供每个透明协商响应的未编码版本。这尤其意味着变量列表中的每个变量至少应以未编码的形式提供。
Like HTTP/1.1, this specification allows proxies to encode or decode relayed or cached responses on the fly, unless explicitly forbidden by a Cache-Control directive. The encoded or decoded response still contains the same variant as far as transparent content negotiation is concerned. Note that HTTP/1.1 requires proxies to add a Warning header if the encoding of a response is changed.
与HTTP/1.1一样，该规范允许代理动态编码或解码中继或缓存响应，除非缓存控制指令明确禁止。就透明内容协商而言，编码或解码响应仍然包含相同的变体。请注意，HTTP/1.1要求代理在响应编码更改时添加警告头。
11 User agent support for transparent negotiation
11对透明协商的用户代理支持
This section specifies the requirements a user agent needs to satisfy in order to support transparent negotiation. If the user agent contains an internal cache, this cache MUST conform to the rules for proxy caches in section 13.
本节规定了用户代理需要满足的要求，以支持透明协商。如果用户代理包含内部缓存，则该缓存必须符合第13节中的代理缓存规则。
If a list response is received when a resource is accessed, the user agent MUST be able to automatically choose, retrieve, and display the best variant, or display an error message if none of the variants are acceptable.
如果在访问资源时收到列表响应，则用户代理必须能够自动选择、检索和显示最佳变体，或者如果任何变体都不可接受，则显示错误消息。
If a choice response is received when a resource is accessed, the usual action is to automatically display the enclosed entity. However, if a remote variant selection algorithm which was enabled could have made a choice different from the choice the local algorithm would make, the user agent MAY apply its local algorithm to any variant list in the response, and automatically retrieve and display another variant if the local algorithm makes an other choice.
如果在访问资源时收到选择响应，通常的操作是自动显示封闭的实体。然而，如果启用的远程变量选择算法可能做出与本地算法将做出的选择不同的选择，则用户代理可以将其本地算法应用于响应中的任何变量列表，并在本地算法做出其他选择时自动检索和显示另一个变量。
When receiving a choice response, a user agent SHOULD check if variant resource is a neighboring variant resource of the negotiable resource. If this is not the case, the user agent SHOULD reject the choice response as a probable spoofing attempt and display an error message, for example by internally replacing the choice response with a 502 (bad gateway) response.
当接收到选择响应时，用户代理应该检查变体资源是否是可协商资源的相邻变体资源。如果情况并非如此，则用户代理应拒绝选择响应作为可能的欺骗尝试，并显示错误消息，例如，通过将选择响应内部替换为502（坏网关）响应。
If the user agent is displaying a variant which is not an embedded or inlined object and which is the result of transparent content negotiation, the following requirements apply.
如果用户代理显示的变量不是嵌入或内联对象，而是透明内容协商的结果，则以下要求适用。
1. The user agent SHOULD allow the user to review a list of all variants bound to the negotiable resource, and to manually retrieve another variant if desired. There are two general ways of providing such a list. First, the information in the Alternates header of the negotiable resource could be used to make an annotated menu of variants. Second, the entity included in a list response of the negotiable resource could be displayed. Note that a list response can be obtained by doing a GET request which only has the "trans" directive in the Negotiate header.
1. 用户代理应允许用户查看绑定到可协商资源的所有变量的列表，并根据需要手动检索另一个变量。提供此类列表的一般方法有两种。首先，可协商资源的Alternates头中的信息可用于创建变量的注释菜单。其次，可以显示可协商资源的列表响应中包含的实体。请注意，可以通过执行GET请求获得列表响应，该请求在协商头中只有“trans”指令。
2. The user agent SHOULD make available though its user interface some indication that the resource being displayed is a negotiated resource instead of a plain resource. It SHOULD also allow the user to examine the variant list included in the Alternates header. Such a notification and review mechanism is needed because of privacy considerations, see section 14.1.
2. 用户代理应该通过其用户界面提供一些指示，表明显示的资源是协商资源而不是普通资源。它还应该允许用户检查Alternates标题中包含的变量列表。出于隐私考虑，需要此类通知和审查机制，见第14.1节。
3. If the user agent shows the URI of the displayed information to the user, it SHOULD be the negotiable resource URI, not the variant URI that is shown. This encourages third parties, who want to refer to the displayed information in their own documents, to make a hyperlink to the negotiable resource as a whole, rather than to the variant resource which happens to be shown. Such correct linking is vital for the interoperability of content across sites. The user agent SHOULD however also provide a means for reviewing the URI of the particular variant which is currently being displayed.
3. 如果用户代理向用户显示所显示信息的URI，那么它应该是可协商的资源URI，而不是显示的变量URI。这鼓励希望在自己的文档中引用显示信息的第三方将可转让资源作为一个整体进行超链接，而不是碰巧显示的变体资源。这种正确的链接对于跨站点内容的互操作性至关重要。但是，用户代理还应提供一种方法，用于查看当前显示的特定变量的URI。
4. Similarly, if the user agent stores a reference to the displayed information for future use, for example in a hotlist, it SHOULD store the negotiable resource URI, not the variant URI.
4. 类似地，如果用户代理存储对所显示信息的引用以供将来使用，例如在热列表中，那么它应该存储可协商资源URI，而不是变量URI。
It is encouraged, but not required, that some of the above functionality is also made available for inlined or embedded objects, and when a variant which was selected manually is being displayed.
鼓励但不是必需的是，当显示手动选择的变量时，上述某些功能也可用于内联或嵌入式对象。
12 Origin server support for transparent negotiation
12源服务器支持透明协商
To implement transparent negotiation on a resource, the origin server MUST be able to send a list response when getting a GET request on the resource. It SHOULD also be able to send appropriate list responses for HEAD requests. When getting a request on a transparently negotiable resource, the origin server MUST NEVER return a response with a 2xx status code or any 3xx status code, except 304, which is not a list, choice, or adhoc response.
要在资源上实现透明协商，源服务器必须能够在获取资源上的GET请求时发送列表响应。它还应该能够为HEAD请求发送适当的列表响应。在透明可协商资源上获取请求时，源服务器不得返回带有2xx状态代码或任何3xx状态代码的响应，304除外，它不是列表、选项或临时响应。
If the request includes a Negotiate header with a "vlist" or "trans" directive, but without any directive which allows the server to select a best variant, a list response MUST ALWAYS be sent, except when the server is performing a server-side override for bug compatibility. If the request includes a Negotiate header with a "vlist" or "guess-small" directive, an Alternates header with the variant list bound to the negotiable resource MUST ALWAYS be sent in any list, choice, or adhoc response, except when the server is performing a server-side override for bug compatibility.
如果请求包含带有“vlist”或“trans”指令的协商头，但没有任何允许服务器选择最佳变体的指令，则必须始终发送列表响应，除非服务器正在执行服务器端覆盖以实现bug兼容性。如果请求包含带有“vlist”或“guess small”指令的协商标头，则必须始终在任何列表、选项或临时响应中发送带有绑定到协商资源的变量列表的备用标头，除非服务器正在执行服务器端覆盖以实现bug兼容性。
If the Negotiate header allows it, the origin server MAY run a remote variant selection algorithm. If the algorithm has sufficient information to choose a best variant, and if the best variant is a neighboring variant, the origin server MAY return a choice response with this variant.
如果协商头允许，源服务器可以运行远程变量选择算法。如果算法有足够的信息来选择最佳变体，并且如果最佳变体是相邻的变体，则源服务器可能会使用此变体返回选择响应。
When getting a request on a transparently negotiable resource from a user agent which does not support transparent content negotiation, the origin server MAY use a custom algorithm to select between sending a list, choice, or adhoc response.
当从不支持透明内容协商的用户代理获取关于透明可协商资源的请求时，源服务器可以使用自定义算法在发送列表、选择或临时响应之间进行选择。
The following table summarizes the rules above.
下表总结了上述规则。
|Req on |Usr agnt|server- | Response may be: |
|trans neg|capable |side +------+------+------+------+------+
|resource?|of TCN? |override?|list |choice|adhoc |normal|error |
+---------+--------+---------+------+------+------+------+------+
| Yes | Yes | No |always|smt(*)|never |never |always|
+---------+--------+---------+------+------+------+------+------+
| Yes | Yes | Yes |always|always|always|never |always|
+---------+--------+---------+------+------+------+------+------+
| Yes | No | - |always|always|always|never |always|
+---------+--------+---------+------+------+------+------+------+
| No | - | - |never |never |never |always|always|
+---------+--------+---------+------+------+------+------+------+
(*) sometimes, when allowed by the Negotiate request header
|Req on |Usr agnt|server- | Response may be: |
|trans neg|capable |side +------+------+------+------+------+
|resource?|of TCN? |override?|list |choice|adhoc |normal|error |
+---------+--------+---------+------+------+------+------+------+
| Yes | Yes | No |always|smt(*)|never |never |always|
+---------+--------+---------+------+------+------+------+------+
| Yes | Yes | Yes |always|always|always|never |always|
+---------+--------+---------+------+------+------+------+------+
| Yes | No | - |always|always|always|never |always|
+---------+--------+---------+------+------+------+------+------+
| No | - | - |never |never |never |always|always|
+---------+--------+---------+------+------+------+------+------+
(*) sometimes, when allowed by the Negotiate request header
Negotiability is a binary property: a resource is either transparently negotiated, or it is not. Origin servers SHOULD NOT vary the negotiability of a resource, or the variant list bound to that resource, based on the request headers which are received. The variant list and the property of being negotiated MAY however change through time. The Cache-Control header can be used to control the propagation of such time-dependent changes through caches.
可协商性是一种二进制属性：资源要么是透明协商的，要么不是。源服务器不应根据收到的请求头更改资源的可协商性或绑定到该资源的变体列表。然而，变量列表和正在协商的属性可能会随着时间的推移而改变。缓存控制头可用于控制此类时间相关更改通过缓存的传播。
It is the responsibility of the author of the negotiable resource to ensure that all resources in the variant list serve the intended content, and that the variant resources do not engage in transparent
可转让资源的作者有责任确保变体列表中的所有资源都服务于预期内容，并且变体资源不参与透明的活动
content negotiation themselves.
内容谈判本身。
If a resource is transparently negotiable, this only has an impact on the GET and HEAD transactions on the resource. It is not possible (under this specification) to do transparent content negotiation on the direct result of a POST request.
如果资源是透明可协商的，那么这只会对资源上的GET和HEAD事务产生影响。（根据本规范）不可能对POST请求的直接结果进行透明内容协商。
However, a POST request can return an unnegotiated 303 (See Other) response which causes the user agent to do a GET request on a second resource. This second resource could then use transparent content negotiation to return an appropriate final response. The figure below illustrates this.
然而，POST请求可以返回未协商的303（参见其他）响应，该响应导致用户代理对第二个资源执行GET请求。然后，第二个资源可以使用透明内容协商来返回适当的最终响应。下图说明了这一点。
Server ______ proxy ______ proxy ______ user
x.org cache cache agent
Server ______ proxy ______ proxy ______ user
x.org cache cache agent
< -------------------------------------
| POST http://x.org/cgi/submit
| <form contents in request body>
|
-------------------------------------- >
303 See Other |
Location: http://x.org/result/OK |
|
< -------------------------------------
| GET http://x.org/result/OK
| small Accept- headers
|
able to choose on
behalf of user agent
|
------------------------------------- >
choice response with |
..result/OK.nl variant |
displays OK.nl
< -------------------------------------
| POST http://x.org/cgi/submit
| <form contents in request body>
|
-------------------------------------- >
303 See Other |
Location: http://x.org/result/OK |
|
< -------------------------------------
| GET http://x.org/result/OK
| small Accept- headers
|
able to choose on
behalf of user agent
|
------------------------------------- >
choice response with |
..result/OK.nl variant |
displays OK.nl
See the HTTP/1.1 specification [1] for details on the 303 (See Other) status code. Note that this status code is not understood by some HTTP/1.0 clients.
有关303（请参阅其他）状态代码的详细信息，请参阅HTTP/1.1规范[1]。请注意，某些HTTP/1.0客户端不理解此状态代码。
13 Proxy support for transparent negotiation
13对透明谈判的代理支持
Transparent content negotiation is an extension on top of HTTP/1.x. It is designed to work through any proxy which only implements the HTTP/1.1 specification [1]. If Expires headers are added as discussed in section 10.7, negotiation will also work though proxies
透明内容协商是HTTP/1.x之上的一个扩展。它被设计为通过任何只实现HTTP/1.1规范的代理来工作[1]。如果按照第10.7节的讨论添加Expires标头，则协商也将通过代理进行
which implement HTTP/1.0 [2]. Thus, every HTTP/1.0 or HTTP/1.1 proxy provides support for transparent content negotiation. However, if it is to be claimed that a HTTP/1.x proxy offers transparent content negotiation services, at least one of the specific optimizations below MUST be implemented.
它们实现了HTTP/1.0[2]。因此，每个HTTP/1.0或HTTP/1.1代理都提供对透明内容协商的支持。但是，如果声称HTTP/1.x代理提供透明的内容协商服务，则必须至少实现以下特定优化之一。
An HTTP/1.x proxy MUST ONLY optimize (change) the HTTP traffic flowing through it in ways which are explicitly allowed by the specification(s) it conforms to. A proxy which supports transparent content negotiation on top of HTTP/1.x MAY perform the optimizations allowed for by HTTP/1.x. In addition, it MAY perform three additional optimizations, defined below, on the HTTP traffic for transparently negotiated resources and their neighboring variant resources.
HTTP/1.x代理只能以其符合的规范明确允许的方式优化（更改）流经它的HTTP流量。在HTTP/1.x之上支持透明内容协商的代理可以执行HTTP/1.x允许的优化。此外，它还可以对透明协商的资源及其相邻的变体资源的HTTP流量执行以下定义的三个额外优化。
First, when getting a request on a transparently negotiable resource from a user agent which supports transparent content negotiation, the proxy MAY return any cached, fresh list response from that resource, even if the selecting request headers, as specified by the Vary header, do not match.
首先，当从支持透明内容协商的用户代理获取关于透明可协商资源的请求时，代理可以从该资源返回任何缓存的、新的列表响应，即使Vary头指定的选择请求头不匹配。
Second, when allowed by the user agent and origin server, a proxy MAY reuse an Alternates header taken from a previous response (section 10.4) to run a remote variant selection algorithm. If the algorithm has sufficient information to choose a best variant, and if the best variant is a neighboring variant, the proxy MAY return a choice response with this variant.
其次，在用户代理和源服务器允许的情况下，代理可以重用先前响应（第10.4节）中的Alternates头来运行远程变量选择算法。如果算法有足够的信息来选择最佳变量，并且如果最佳变量是相邻变量，则代理可能会返回带有此变量的选择响应。
Third, if a proxy receives a choice response, it MAY extract and cache the normal response embedded therein, as described in section 10.5.
第三，如果代理接收到选择响应，它可以提取并缓存嵌入其中的正常响应，如第10.5节所述。
14 Security and privacy considerations
14安全和隐私注意事项
Accept- headers, in particular Accept-Language headers, may reveal information which the user would rather keep private unless it will directly improve the quality of service. For example, a user may not want to send language preferences to sites which do not offer multi-lingual content. The transparent content negotiation mechanism allows user agents to omit sending of the Accept-Language header by default, without adversely affecting the outcome of the negotiation process if transparently negotiated multi-lingual content is accessed.
Accept-Header，特别是Accept-Language Header，可能会显示用户希望保密的信息，除非它会直接提高服务质量。例如，用户可能不希望向不提供多语言内容的站点发送语言首选项。透明内容协商机制允许用户代理在默认情况下省略接受语言报头的发送，如果访问透明协商的多语言内容，则不会对协商过程的结果产生不利影响。
However, even if Accept- headers are never sent, the automatic selection and retrieval of a variant by a user agent will reveal a preference for this variant to the server. A malicious service author could provide a page with `fake' negotiability on (ethnicity-correlated) languages, with all variants actually being the same English document, as a means of obtaining privacy-sensitive information. Such a plot would however be visible to an alert victim if the list of available variants and their properties is reviewed.
但是，即使从不发送Accept-Header，用户代理自动选择和检索变体也会向服务器显示对该变体的偏好。恶意服务作者可以提供一个在（种族相关）语言上具有“假”可协商性的页面，所有变体实际上都是相同的英文文档，以此作为获取隐私敏感信息的手段。但是，如果审查了可用变体及其属性列表，则警报受害者可以看到这样的图。
Some additional privacy considerations connected to Accept- headers are discussed in [1].
[1]中讨论了与Accept-Header相关的一些其他隐私注意事项。
The caching optimization in section 10.5 gives the implementer of a negotiable resource control over the responses cached for all neighboring variant resources. This is a security problem if a neighboring variant resource belongs to another author. To provide security in this case, the HTTP server will have to filter the Content-Location headers in the choice responses generated by the negotiable resource implementation.
第10.5节中的缓存优化为可协商资源的实现者提供了对所有相邻变量资源的缓存响应的控制。如果相邻的变体资源属于其他作者，则这是一个安全问题。为了在这种情况下提供安全性，HTTP服务器必须在可协商资源实现生成的选择响应中过滤内容位置头。
Malicious servers could use transparent content negotiation as a means of obtaining information about security holes which may be present in user agents. This is a risk in particular for negotiation on the availability of scripting languages and libraries.
恶意服务器可以使用透明内容协商作为获取有关用户代理中可能存在的安全漏洞的信息的手段。这对于就脚本语言和库的可用性进行谈判来说尤其是一个风险。
15 Internationalization considerations
15国际化考虑
This protocol defines negotiation facilities which can be used for the internationalization of web content. For the internationalization of list response bodies (section 10.1), HTTP/1.0 style negotiation (section 4.2) can be used.
该协议定义了可用于web内容国际化的协商设施。对于列表响应主体的国际化（第10.1节），可以使用HTTP/1.0风格的协商（第4.2节）。
16 Acknowledgments
16致谢
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, Martin J. Duerst, Roy T. Fielding, Jim Gettys, Yaron Goland, Dirk van Gulik, Ted Hardie, Graham Klyne, Scott Lawrence, Larry Masinter, Jeffrey Mogul, Henrik Frystyk Nielsen, Frederick G.M. Roeber, Paul Sutton, and Klaus Weide and Mark Wood.
HTTP内容协商的工作至少从1993年就开始了。作者无法追溯本文件中包含的许多想法的起源。HTTP工作组的许多成员对本规范中的协商模型做出了贡献。作者希望感谢对本文件早期版本发表评论的个人，包括Brian Behlendorf、Daniel DuBois、Martin J.Duerst、Roy T.Fielding、Jim Gettys、Yaron Goland、Dirk van Gulik、Ted Hardie、Graham Klyne、Scott Lawrence、Larry Masinter、Jeffrey Mogul、Henrik Frystyk Nielsen、Frederick G.M.Roeber、，保罗·萨顿、克劳斯·魏德和马克·伍德。
17 References
17参考文献
[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] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[2] Berners Lee，T.，Fielding，R.，和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[3] Holtman, K., and A. Mutz, "HTTP Remote Variant Selection Algorithm -- RVSA/1.0", RFC 2296, March 1998.
[3] Holtman，K.和A.Mutz，“HTTP远程变量选择算法——RVSA/1.0”，RFC2296，1998年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[5] “UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
18 Authors' Addresses
18作者地址
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
传真+14158574691电子邮件：mutz@hpl.hp.com
19 Appendix: Example of a local variant selection algorithm
19附录：局部变量选择算法示例
A negotiating user agent will choose the best variant from a variant list with a local variant selection algorithm. This appendix contains an example of such an algorithm.
协商用户代理将使用本地变量选择算法从变量列表中选择最佳变量。本附录包含此类算法的示例。
The inputs of the algorithm are a variant list from an Alternates header, and an agent-side configuration database, which contains
该算法的输入是来自Alternates头的变量列表和代理端配置数据库，其中包含
- the feature set of the current request,
- 当前请求的功能集，
- a collection of quality values assigned to media types, languages, and charsets for the current request, following the model of the corresponding HTTP/1.1 [1] Accept- headers,
- 为当前请求分配给媒体类型、语言和字符集的质量值集合，遵循相应HTTP/1.1[1]Accept-Header的模型，
- a table which lists `forbidden' combinations of media types and charsets, i.e. combinations which cannot be displayed because of some internal user agent limitation.
- 列出媒体类型和字符集的“禁止”组合的表格，即由于某些内部用户代理限制而无法显示的组合。
The output of the algorithm is either the best variant, or the conclusion that none of the variants are acceptable.
算法的输出要么是最佳变量，要么是所有变量都不可接受的结论。
As a first step in the local variant selection algorithm, the overall qualities associated with all variant descriptions in the list are computed.
作为局部变量选择算法的第一步，将计算与列表中所有变量描述相关联的总体质量。
The overall quality Q of a variant description is the value
变量描述的总体质量Q是值
Q = round5( qs * qt * qc * ql * qf * qa )
Q = round5( qs * qt * qc * ql * qf * qa )
where rounds5 is a function which rounds a floating point value to 5 decimal places after the point. It is assumed that the user agent can run on multiple platforms: the rounding function makes the algorithm independent of the exact characteristics of the underlying floating point hardware.
其中，rounds5是一个函数，它将浮点值舍入到小数点后5位。假设用户代理可以在多个平台上运行：舍入函数使算法独立于底层浮点硬件的确切特性。
The factors qs, qt, qc, ql, qf, and qa are determined as follows.
因子qs、qt、qc、ql、qf和qa的确定如下。
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. Otherwise, it is the quality value assigned to this type by the configuration database. If the database does not assign a value, then the factor is 0.
qt如果变量描述中没有类型属性，则媒体类型质量因子为1。否则，它是配置数据库分配给此类型的质量值。如果数据库未指定值，则系数为0。
qc The charset quality factor is 1 if there is no charset attribute in the variant description. Otherwise, it is the quality value assigned to this charset by the configuration database. If the database does not assign a value, then the factor is 0.
qc如果变量描述中没有字符集属性，则字符集质量因子为1。否则，它是配置数据库分配给该字符集的质量值。如果数据库未指定值，则系数为0。
ql The language quality factor is 1 if there is no language attribute in the variant description. Otherwise, it is the highest quality value the configuration database assigns to any of the languages listed in the language attribute. If the database does not assign a value to any of the languages listed, then the factor is 0.
ql如果变量描述中没有语言属性，则语言质量因子为1。否则，它是配置数据库分配给“语言”属性中列出的任何语言的最高质量值。如果数据库未为列出的任何语言赋值，则系数为0。
qf The features quality factor is 1 if there is no features attribute in the variant description. Otherwise, it is the quality degradation factor computed for the features attribute using the feature set of the current request.
qf如果变量描述中没有特征属性，则特征质量因子为1。否则，它是使用当前请求的特征集为特征属性计算的质量降级因子。
qa The quality adjustment factor is 0 if the variant description lists a media type - charset combination which is `forbidden' by the table, and 1 otherwise.
qa如果变量描述列出了表中“禁止”的媒体类型-字符集组合，则质量调整系数为0，否则为1。
As an example, if a variant list contains the variant description
例如，如果变量列表包含变量描述
{"paper.2" 0.7 {type text/html} {language fr}}
{"paper.2" 0.7 {type text/html} {language fr}}
and if the configuration database contains the quality value assignments
以及配置数据库是否包含质量值分配
types: text/html;q=1.0, type application/postscript;q=0.8
languages: en;q=1.0, fr;q=0.5
types: text/html;q=1.0, type application/postscript;q=0.8
languages: en;q=1.0, fr;q=0.5
then the local variant selection algorithm will compute the overall quality for the variant description as follows:
然后，局部变量选择算法将计算变量描述的总体质量，如下所示：
{"paper.2" 0.7 {type text/html} {language fr}}
| | |
| | |
V V V
round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000
{"paper.2" 0.7 {type text/html} {language fr}}
| | |
| | |
V V V
round5 ( 0.7 * 1.0 * 0.5 ) = 0.35000
With same configuration database, the variant list
对于相同的配置数据库，变量列表
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
{"paper.1" 0.9 {type text/html} {language en}},
{"paper.2" 0.7 {type text/html} {language fr}},
{"paper.3" 1.0 {type application/postscript} {language en}}
would yield the following computations:
将产生以下计算结果：
round5 ( qs * qt * qc * ql * qf * qa ) = Q
--- --- --- --- --- ---
paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000
paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 * 1.0 = 0.35000
paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 * 1.0 = 0.80000
round5 ( qs * qt * qc * ql * qf * qa ) = Q
--- --- --- --- --- ---
paper.1: 0.9 * 1.0 * 1.0 * 1.0 * 1.0 * 1.0 = 0.90000
paper.1: 0.7 * 1.0 * 1.0 * 0.5 * 1.0 * 1.0 = 0.35000
paper.3: 1.0 * 0.8 * 1.0 * 1.0 * 1.0 * 1.0 = 0.80000
Using all computed overall quality values, the end result of the local variant selection algorithm is determined as follows.
使用所有计算的总体质量值，局部变量选择算法的最终结果如下所示。
If all overall quality values are 0, then the best variant is the fallback variant, if there is one in the list, else the result is the conclusion that none of the variants are acceptable.
如果所有总体质量值均为0，则最佳变量为回退变量，如果列表中有回退变量，则结果为所有变量均不可接受。
If at least one overall quality value is greater than 0, then the best variant is the variant which has the description with the highest overall quality value, or, if there are multiple variant descriptions which share the highest overall quality value, the variant of the first variant description in the list which has this highest overall quality value.
如果至少有一个总体质量值大于0，则最佳变体是具有最高总体质量值描述的变体，或者，如果存在多个共享最高总体质量值的变体描述，列表中具有最高总体质量值的第一个变量描述的变量。
Consider the following variant list:
考虑下面的变量列表：
{"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}},
{"paper.english" 1.0 {language en} {charset ISO-8859-1}}
It could be the case that the user prefers the language "el" over "en", while the user agent can render "ISO-8859-1" better than "ISO-8859-7". The result is that in the language dimension, the first variant is best, while the second variant is best in the charset dimension. In this situation, it would be preferable to choose the first variant as the best variant: the user settings in the language dimension should take precedence over the hard-coded values in the charset dimension.
可能的情况是，用户更喜欢“el”而不是“en”，而用户代理可以更好地呈现“ISO-8859-1”而不是“ISO-8859-7”。结果是，在语言维度，第一个变量最好，而在字符集维度，第二个变量最好。在这种情况下，最好选择第一个变量作为最佳变量：语言维度中的用户设置应优先于字符集维度中的硬编码值。
To express this ranking between dimensions, the user agent configuration database should have a higher spread in the quality values for the language dimension than for the charset dimension. For example, with
为了表示维度之间的这种排名，用户代理配置数据库中语言维度的质量值应比字符集维度的质量值更高。例如，与
languages: el;q=1.0, en-gb;q=0.7, en;q=0.6, da;q=0, ...
语言：el；q=1.0，en gb；q=0.7，en；q=0.6，da；q=0。。。
charsets: ISO-8859-1;q=1.0, ISO-8859-7;q=0.95, ISO-8859-5;q=0.97, unicode-1-1;q=0, ...
字符集：ISO-8859-1；q=1.0，ISO-8859-7；q=0.95，ISO-8859-5；q=0.97，unicode-1-1；q=0。。。
the first variant will have an overall quality of 0.95000, while the second variant will have an overall quality 0.70000. This makes the first variant the best variant.
第一种变体的总体质量为0.95000，而第二种变体的总体质量为0.70000。这使得第一个变体成为最佳变体。
20 Appendix: feature negotiation examples
20附录：特征谈判示例
This appendix contains examples of the use of feature tags in variant descriptions. The tag names used here are examples only, they do not in general reflect the tag naming scheme proposed in [4].
本附录包含在变体描述中使用特征标记的示例。此处使用的标签名称仅为示例，它们通常不反映[4]中提出的标签命名方案。
Feature tags can be used in variant lists to express the quality degradation associated with the presence or absence of certain features. One example is
特征标签可用于变量列表中，以表示与某些特征的存在或不存在相关的质量下降。一个例子是
{"index.html.plain" 0.7 },
{"index.html" 1.0 {features tables frames}}
{"index.html.plain" 0.7 },
{"index.html" 1.0 {features tables frames}}
Here, the "{features tables frames}" part expresses that index.html uses the features tagged as tables and frames. If these features are absent, the overall quality of index.html degrades to 0. Another example is
这里，{features tables frames}部分表示index.html使用标记为表和框架的功能。如果缺少这些功能，index.html的总体质量将降低到0。另一个例子是
{"home.graphics" 1.0 {features !textonly}},
{"home.textonly" 0.7 }
{"home.graphics" 1.0 {features !textonly}},
{"home.textonly" 0.7 }
where the "{features !textonly}" part expresses that home.graphics requires the absence of the textonly feature. If the feature is present, the overall quality of home.graphics degrades to 0.
其中，{features！textonly}部分表示home.graphics需要缺少textonly功能。如果存在该功能，home.graphics的整体质量将降低到0。
The absence of a feature need not always degrade the overall quality to 0. In the example
缺少特性并不一定会将总体质量降低到0。在这个例子中
{"x.html.1" 1.0 {features fonts;-0.7}}
{"x.html.1" 1.0 {features fonts;-0.7}}
the absence of the fonts feature degrades the quality with a factor of 0.7. Finally, in the example
缺少字体功能会降低质量，降低系数为0.7。最后，在示例中
{"y.html" 1.0 {features [blebber wolx] }}
{"y.html" 1.0 {features [blebber wolx] }}
The "[blebber wolx]" expresses that y.html requires the presence of the blebber feature or the wolx feature. This construct can be used in a number of cases:
“[bleber-wolx]”表示y.html需要存在bleber特性或wolx特性。此结构可用于多种情况：
1. blebber and wolx actually tag the same feature, but they were registered by different people, and some user agents say they support blebber while others say they support wolx.
1. blebber和wolx实际上标记了相同的功能，但它们是由不同的人注册的，一些用户代理说他们支持blebber，而其他人说他们支持wolx。
2. blebber and wolx are HTML tags of different vendors which implement the same functionality, and which are used together in y.html without interference.
2. blebber和wolx是不同供应商的HTML标记，它们实现相同的功能，并且在y.HTML中一起使用而不受干扰。
3. blebber and wolx are HTML tags of different vendors which implement the same functionality, and y.html uses the tags in a conditional HTML construct.
3. blebber和wolx是实现相同功能的不同供应商的HTML标记，y.HTML在条件HTML构造中使用这些标记。
4. blebber is a complicated HTML tag with only a sketchy definition, implemented by one user agent vendor, and wolx indicates implementation of a well-defined subset of the blebber tag by some other vendor(s). y.html uses only this well-defined subset.
4. blebber是一个复杂的HTML标记，只有一个粗略的定义，由一个用户代理供应商实现，wolx表示由其他一些供应商实现了blebber标记的定义良好的子集。y、 html只使用这个定义良好的子集。
As an example of negotiation in a numeric area, the following variant list describes four variants with title graphics designed for increasing screen widths:
作为数字区域协商的示例，以下变体列表描述了四种变体，其标题图形旨在增加屏幕宽度：
{"home.pda" 1.0 {features screenwidth=[-199] }},
{"home.narrow" 1.0 {features screenwidth=[200-599] }},
{"home.normal" 1.0 {features screenwidth=[600-999] }},
{"home.wide" 1.0 {features screenwidth=[1000-] }},
{"home.normal"}
{"home.pda" 1.0 {features screenwidth=[-199] }},
{"home.narrow" 1.0 {features screenwidth=[200-599] }},
{"home.normal" 1.0 {features screenwidth=[600-999] }},
{"home.wide" 1.0 {features screenwidth=[1000-] }},
{"home.normal"}
The last element of the list specifies a safe default for user agents which do not implement screen width negotiation. Such user agents will reject the first four variants as unusable, as they seem to rely on a feature which they do not understand.
列表的最后一个元素为未实现屏幕宽度协商的用户代理指定安全默认值。这样的用户代理将拒绝前四个变体，因为它们似乎依赖于一个他们不了解的特性。
When designing a new feature tag, it is important to take into account that existing user agents, which do not recognize the new tag will treat the feature as absent. In general, a new feature tag needs to be designed in such a way that absence of the tag is the default case which reflects current practice. If this design principle is ignored, the resulting feature tag will generally be unusable.
在设计新的功能标签时，重要的是要考虑到现有的用户代理（不识别新标签）会将该功能视为不存在。一般来说，新的功能标签需要以这样一种方式设计，即没有标签是反映当前实践的默认情况。如果忽略此设计原则，则生成的功能标签通常将不可用。
As an example, one could try to support negotiation between monochrome and color content by introducing a `color' feature tag, the presence of which would indicate the capability to display color graphics. However, if this new tag is used in a variant list, for example
例如，可以通过引入“颜色”特征标签来支持单色和彩色内容之间的协商，该标签的存在将表明显示彩色图形的能力。但是，如果在变量列表中使用此新标记，例如
{"rainbow.gif" 1.0 {features color} }
{"rainbow.gif" 1.0 {features color} }
{"rainbow.mono.gif" 0.6 {features !color}}
{"rainbow.mono.gif" 0.6 {features !color}}
then existing user agents, which would not recognize the color tag, would all display the monochrome rainbow. The color tag is therefore unusable in situations where optimal results for existing user agents are desired. To provide for negotiation in this area, one must introduce a `monochrome' feature tag; its presence indicates that the user agent can only render (or the user prefers to view) monochrome graphics.
然后，现有的用户代理将无法识别颜色标签，它们都将显示单色彩虹。因此，在需要现有用户代理的最佳结果的情况下，颜色标签不可用。为了在这一领域进行谈判，必须引入“单色”特征标签；它的存在表明用户代理只能渲染（或用户更喜欢查看）单色图形。
21 Appendix: origin server implementation considerations
21附录：源服务器实施注意事项
Transparent content negotiation has been designed to allow a broad range of implementation options at the origin server side. A very minimal implementation can be done using the CGI interface. The CGI script below is an example.
透明内容协商的设计允许在源服务器端提供广泛的实现选项。使用CGI接口可以实现非常小的实现。下面的CGI脚本就是一个例子。
#!/bin/sh
#!/bin/sh
cat - <<'blex'
TCN: list
Alternates: {"stats.tables.html" 1.0 {type text/html} {features
tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95
{type application/postscript}}
Vary: *
Content-Type: text/html
cat - <<'blex'
TCN: list
Alternates: {"stats.tables.html" 1.0 {type text/html} {features
tables}}, {"stats.html" 0.8 {type text/html}}, {"stats.ps" 0.95
{type application/postscript}}
Vary: *
Content-Type: text/html
<title>Multiple Choices for Web Statistics</title>
<h2>Multiple Choices for Web Statistics:</h2>
<ul>
<li><a href=stats.tables.html>Version with HTML tables</a>
<p>
<li><a href=stats.html>Version without HTML tables</a>
<p>
<li><a href=stats.ps>Postscript version</a>
</ul>
blex
<title>Multiple Choices for Web Statistics</title>
<h2>Multiple Choices for Web Statistics:</h2>
<ul>
<li><a href=stats.tables.html>Version with HTML tables</a>
<p>
<li><a href=stats.html>Version without HTML tables</a>
<p>
<li><a href=stats.ps>Postscript version</a>
</ul>
blex
The Alternates header in the above script must be read as a single line. The script always generates a list response with the 200 (OK) code, which ensures compatibility with non-negotiating HTTP/1.0 agents.
上述脚本中的Alternates标头必须作为单行读取。该脚本始终使用200（OK）代码生成列表响应，这确保了与非协商HTTP/1.0代理的兼容性。
Sophisticated HTTP servers could make a transparent negotiation module available to content authors. Such a module could incorporate a remote variant selection algorithm and an implementation of the algorithm for generating choice responses (section 10.2). The definition of interfaces to such modules is beyond the scope of this specification.
复杂的HTTP服务器可以为内容作者提供透明的协商模块。该模块可包含远程变量选择算法和生成选择响应的算法实现（第10.2节）。此类模块接口的定义超出本规范的范围。
Web publishing tools could automatically generate several variants of a document (for example the original TeX version, a HTML version with tables, a HTML version without tables, and a Postscript version), together with an appropriate variant list in the interface format of a HTTP server transparent negotiation module. This would allow documents to be published as transparently negotiable resources.
Web发布工具可以自动生成文档的多个变体（例如原始TeX版本、带表的HTML版本、不带表的HTML版本和Postscript版本），以及HTTP服务器透明协商模块接口格式的适当变体列表。这将使文件能够作为透明的可转让资源发布。
22 Appendix: Example of choice response construction
22附录：选择响应构造示例
The following is an example of the construction of a choice response by a proxy cache which supports HTTP/1.1 and transparent content negotiation. The use of the HTTP/1.1 conditional request mechanisms is also shown.
下面是通过支持HTTP/1.1和透明内容协商的代理缓存构造choice响应的示例。还显示了HTTP/1.1条件请求机制的使用。
Assume that a user agent has cached a variant list with the validator "1234" for the negotiable resource http://x.org/paper. Also assume that it has cached responses from two neighboring variants, with the entity tags "gonkyyyy" and W/"a;b". Assume that all three user agent cache entries are stale: they would need to be revalidated before the user agent can use them. If http://x.org/paper accessed in this situation, the user agent could send the following request to its proxy cache:
假设用户代理缓存了可协商资源的带有验证器“1234”的变体列表http://x.org/paper. 还假设它缓存了来自两个相邻变体的响应，实体标记为“gonkyyyy”和W/“a；b”。假设所有三个用户代理缓存项都已过时：在用户代理可以使用它们之前，需要重新验证它们。如果http://x.org/paper 在这种情况下，用户代理可以向其代理缓存发送以下请求：
GET /paper HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy;1234", W/"a;b;1234"
GET /paper HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy;1234", W/"a;b;1234"
Assume that the proxy cache has cached the same three items as the user agent, but that it has revalidated the variant list 8000 seconds ago, so that the list is still fresh for the proxy. This means that the proxy can run a remote variant selection algorithm on the list and the incoming request.
假设代理缓存缓存了与用户代理相同的三个项目，但它在8000秒前重新验证了变量列表，因此该列表对于代理仍然是新的。这意味着代理可以对列表和传入请求运行远程变量选择算法。
Assume that the remote algorithm is able to choose paper.html.en as the best variant. The proxy can now construct a choice response, using the algorithm in section 10.2. In steps 1 and 2 of the algorithm, the proxy can construct the following conditional request on the best variant, and send it to the origin server:
假设远程算法能够选择paper.html.en作为最佳变体。代理现在可以使用第10.2节中的算法构造选择响应。在算法的步骤1和2中，代理可以在最佳变体上构造以下条件请求，并将其发送到源服务器：
GET /paper.html.en HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy", W/"a;b"
Via: 1.1 fred
GET /paper.html.en HTTP/1.1
Host: x.org
User-Agent: WuxtaWeb/2.4
Negotiate: 1.0
Accept: text/html, application/postscript;q=0.4, */*
Accept-Language: en
If-None-Match: "gonkyyyy", W/"a;b"
Via: 1.1 fred
On receipt of the response
在收到答复时
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy"
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy"
from the origin server, the proxy can use its freshly revalidated paper.html.en cache entry to expand the response to a non-304 response:
从源服务器，代理可以使用其新重新验证的paper.html.en缓存项将响应扩展为非304响应：
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Etag: "gonkyyyy"
Via: 1.1 fred
Age: 0
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Etag: "gonkyyyy"
Via: 1.1 fred
Age: 0
<title>A paper about ....
<title>A paper about ....
Using this 200 response, the proxy can construct a choice response in step 4 of the algorithm:
使用该200响应，代理可以在算法的步骤4中构造选择响应：
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.html.en
HTTP/1.1 200 OK
Date: Tue, 11 Jun 1996 20:05:31 GMT
TCN: choice
Content-Type: text/html
Last-Modified: Mon, 10 Jun 1996 10:01:14 GMT
Content-Length: 5327
Cache-control: max-age=604800
Content-Location: paper.html.en
Alternates: {"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}}
Alternates: {"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}}
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
Etag: "gonkyyyy;1234"
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
<title>A paper about ....
<title>A paper about ....
The choice response can subsequently be shortened to a 304 response, because of the If-None-Match header in the original request from the user agent. Thus, the proxy can finally return
由于来自用户代理的原始请求中存在If None Match头，因此choice响应随后可以缩短为304响应。因此，代理最终可以返回
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy;1234"
Content-Location: paper.html.en
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
HTTP/1.1 304 Not Modified
Date: Tue, 11 Jun 1996 20:05:31 GMT
Etag: "gonkyyyy;1234"
Content-Location: paper.html.en
Vary: negotiate, accept, accept-language
Expires: Thu, 01 Jan 1980 00:00:00 GMT
Via: 1.1 fred
Age: 8000
to the user agent.
到用户代理。
23 Full Copyright Statement
23版权声明全文
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。