关于内容协商(Content Negotiation)

一个资源可能会有多种不同的表现形式，比如，可能会有不同语言或者媒体类型的版本甚至其组合。最常用的选择方法是提供一个索引页以供选择。但是由于浏览器可以在请求头信息中提供其首选项的表现形式，因此就有可能让服务器进行自动选择。比如，浏览器可以表明希望看见法语的信息，如果没有，英语的也行。如需仅请求法语的表现形式，浏览器可以发出：

注意：此首选项信息仅当存在多种可选的语言表现形式时才有效。

下面是一个更复杂的请求，浏览器表明，可以接受法语和英语，但最好是法语；接受各种媒体类型，最好是HTML，但纯文件或其他文本类型也可以；最好是GIF或JPEG，但其他媒体类型也可以，并允许其他媒体类型作为最终表现形式：

Apache支持HTTP/1.1规范中定义的"服务器驱动"的内容协商， 可以完全地支持Accept、Accept-Language、Accept-Charset、Accept-Encoding请求头，这些是RFC2295和RFC2296中定义的实验协商协议，但是不支持这些RFC中定义的"功能协商"。

资源(resource)是一个在URI(RFC2396)中定义的概念上的实体。一个HTTP服务器，比如Apache，以表现形式(representation)提供对其命名空间中资源的访问，各种表现形式由已定义的媒体类型、字符集和编码的字节流构成。任何一个特定的时刻，一个资源可以没有，或者有一个，或者有多个表现形式。如果有多个表现形式存在，则称该资源是可协商的(negotiable)，其各种表现形式称为变种(variant)。而一个可协商的资源的各种变种的区别途径称为变元(dimension)。

MIME类型：application/x-type-map )。要使用这个功能，必须在配置中建立处理器，以定义一个文件后缀为type-map，最好的方法是在配置文件中这样设置：

AddHandler type-map .var

类型表文件应该与所描述的资源同名，且对每个有效变种都有一个块(entry)，每个块由若干连续的HTTP头行组成，不同变种的块用空行分开，块中不允许有空行。习惯上，类型表都以一个描述总体性质的组合块作为开始(这不是必须的，如果有也会被忽略)。下例是一个描述资源foo的命名为foo.var的类型表文件：

URI: foo

URI: foo.en.html
Content-type: text/html
Content-language: en

URI: foo.fr.de.html
Content-type: text/html;charset=iso-8859-2
Content-language: fr, de


注意：即使将MultiViews设置为 On ，类型表仍然优先于文件后缀名。如果不同的变种具有不同的资源品质，就可以对媒体类型使用"qs"参数来表示这种不同。下例演示了一个图片的 jpeg, gif, ASCII-art 三个有效变种：

URI: foo

URI: foo.jpeg
Content-type: image/jpeg; qs=0.8

URI: foo.gif
Content-type: image/gif; qs=0.5

URI: foo.txt
Content-type: text/plain; qs=0.01


qs的取值范围是0.000到1.000，取值为0.000的变种永远不会被选择，没有指定qs值的变种其qs值为1.0。qs值表示一个变种相对于其他变种的"品质"，比如在表现一张照片时，jpeg通常比字符构图有更高的品质；而如果要表现的本来就是一个ASCII-art ，那么当然字符构图就会比jpeg文件有更高的品质。因此，qs的值取决于变种所表现的资源本身。

mod_negotation类型表文档中有完整的HTTP头的列表。

AllowOverride)文件中的<Directory>、<Location>、<Files>配置段中，用Options指令来指定。注意，Options All 并不会设置MultiViews ，你必须明确地指定。

MultiViews的效果是：如果服务器收到对/some/dir/foo的请求，而/some/dir/foo并不存在，但是如果/some/dir启用了MultiViews ，则服务器会查找这个目录下所有的foo.* 文件，并有效地伪造一个说明这些foo.* 文件的类型表，分配给他们相同的媒体类型及内容编码，并选择其中最合适的匹配返回给客户。

MultiViews还可以在服务器检索一个目录时，用于DirectoryIndex指令搜索的文件名。如果设置了：

DirectoryIndex index

而index.html和index.html3并存，则服务器会作一个权衡；如果都没有，但是有index.cgi ，则服务器会执行它。

如果一个目录中没有任何文件具有mod_mime可以识别的表示其字符集、内容类型、语言和编码的后缀，那么其结果将取决于MultiViewsMatch指令的设置，这个指令决定了在MultiViews协商中将使用的处理器、过滤器和其他后缀类型。

协商的方法

Apache从一个类型表或者某个目录的文件名中得到一个资源变种列表以后，会使用两种方法之一选择可能的"最佳"变种返回给客户。使用Apache的内容协商功能并不需要了解其细节，以下文档对这些方法加以详细说明，供有兴趣的人看看。

协商有两种方法：

1. 使用Apache算法的服务器驱动协商 是通常情况下的默认方法。使用这个算法(下面有详细的描述)，为了得到更好的效果，Apache有时会"打乱"一个特定变元(dimension)的品质因子，其方法稍后会详细阐述。
2. 透明内容协商 仅当浏览器明确地用RFC2295中定义的机制发出请求时才使用。这种方法可以给予浏览器对"最佳"变种选择的完全控制，因此其效果也取决于浏览器使用的算法。作为透明协商过程的一部分，浏览器可以要求Apache执行RFC2296中定义的"远程变种选择算法"。

协商的变元(Dimension)

Apache协商算法

Apache使用下述算法选择可能的"最佳"变种返回给浏览器。此算法不能被再配置。其过程如下：

1. 首先，对每个协商变元，检查其适当的Accept* 头，并对每个变种指定一个品质。如果一个变元的Accept* 头指示不接受这个变种，则被剔除。如果最终没有变种了，则转到步骤4。
2. 顺序执行以下的测试，使用逐步剔除的方法来选择"最佳"变种。不能通过测试的变种将被剔除。每个测试完成后，如果仅剩一个变种，则作为最佳匹配，转到步骤3；如果多于一个，则继续下一个测试。
   1. 将Accept头的品质因子乘以该变种媒体类型的还原品质因子，选择乘积最高者。
   2. 选择语言品质因子最高的变种。
   3. 使用Accept-Language头中的语言顺序(如果存在的话)，或者使用LanguagePriority指令中的语言顺序(如果存在的话)选择最匹配的语言。
   4. 选择最高"等级"媒体参数的变种(用以确定text/html的媒体类型)。
   5. 选择Accept-Charset头中指定的最佳字符集媒体参数的变种。如果没有明确指定，则使用ISO-8859-1字符集。具有text/* 媒体类型而没有明确地与一个特定字符集关联的变种，将使用ISO-8859-1。
   6. 选择与之关联字符集不是ISO-8859-1的变种，如果没有这样的变种，则选择所有的变种。
   7. 选择最佳编码的变种。如果存在用户代理可以接受的编码的变种，则选择之；否则，如果存在混合编码的或者未编码的变种，则选择未编码的变种。如果所有的变种都是编码的，或者所有变种都是未编码的，则选择所有的变种。
   8. 选择内容长度最小的变种。
   9. 选择剩余变种的最前一个，这个变种或是类型表文件中的第一个，或从目录中读取变种被时，以ASCII编码顺序的第一个文件。
3. 这时，此算法已经选择了一个"最佳"变种，并将之返回作为响应。HTTP响应头的Vary会指明协商的变元(浏览器和缓存可以利用此信息缓存该资源)。
4. 如果没有一个变种被选择(因为没有一种可以被浏览器接受)，则返回一个状态值为406响应体，并包含一个HTML格式的有效变种列表，同样，在HTTP头的Vary中指明了变种的变元。

ForceLanguagePriority指令可以屏蔽这两种错误信息，并接管由LanguagePriority指令控制的服务器裁定机制。

服务器还会在匹配失败时尝试用语言子集来匹配。例如，如果一个客户请求了一个语言是en-GB的英国英语的页面，而服务器只支持HTTP/1.1标准的简单的en 。(注意，在Accept-Language中指定en-GB而不是en几乎绝对是个错误，因为它似乎暗示阅读的人懂英国英语却不懂大众英语。而不幸的是，许多流行的客户端的默认配置却是这样的)。如果没有可以匹配的语言，服务器将会忽略其语言子集的设定，返回"No Acceptable Variants"错误，或者按LanguagePriority指令作妥协。Apache会隐含地在客户可接受语言的列表中附加一个具有很低品质值的父语言，但是，如果客户请求"en-GB; q=0.9, fr; q=0.8" 那么将返回"fr"的文本，这对遵循HTTP/1.1标准以使正确配置的浏览器能正常工作是必须的。

为了支持用于确定用户首选语言的高级技术(比如cookies或特殊的URL路径)，从2.0.47版本起mod_negotiation模块开始支持prefer-language环境变量。如果存在并且包含一个语言标签，mod_negotiation模块将会尝试选择一个匹配的变种。如果不存在这样的变种，将会使用上述通常的协商过程。

示例

SetEnvIf Cookie "language=(.+)" prefer-language=$1
Header append Vary cookie

透明内容协商的扩展

Apache在变种列表中使用了一个新的{encoding ..}元素来标记变种，从而扩展了透明内容协商协议(RFC2295)。实现RVSA/1.0算法(RFC2296)的目的是识别列表中被编码的变种，作为可以被Accept-Encoding请求头接受的候选变种。在选择最佳变种之前，RVSA/1.0的实现不会对品质因子作四舍五入的运算。

mod_mime文档)。

一个典型的有MIME类型后缀的文件(如html)，其后缀可以是编码后缀(如gz)，也可以是语言变种后缀(如en)

例如：

• foo.en.html
• foo.html.en
• foo.en.html.gz

文件名和有效及无效超链的例子：

文件名	有效超链	无效超链
foo.html.en	foo foo.html	-
foo.en.html	foo	foo.html
foo.html.en.gz	foo foo.html	foo.gz foo.html.gz
foo.en.html.gz	foo	foo.html foo.html.gz foo.gz
foo.gz.html.en	foo foo.gz foo.gz.html	foo.html
foo.html.gz.en	foo foo.html foo.html.gz	foo.gz

可以看出，上表中使用没有任何后缀的超链(如foo)总是可行的，其优点是可以隐藏rsp. 文件的真实类型，而可以在将来作更改，比如，不用修改超链本身，而改变html为shtml或cgi 。

如果希望在超链中继续使用MIME类型(如foo.html)，则语言后缀(还包括一个编码后缀)必须出现在MIME类型后缀的右边(如foo.html.en)。

CacheNegotiatedDocs指令可以允许缓存服从协商的请求。此指令应该出现在主服务器或虚拟主机的配置中，没有参数，并且对来自HTTP/1.1客户端的请求没有影响。

对于遵守HTTP/1.1规范的客户端，Apache发送一个Vary应答头以指定该应答的协商变元。缓存可以使用这个信息来判断一个其后的请求是否可以从本地副本中提供服务。为了鼓励缓存使用本地副本而不是协商变元，请设置force-no-vary环境变量。

Language Negotiation Notes，但是注意，此文档可能没有升级以包含Apache2.0中的改变。