• 本章主要讲解了一种机制————同样的url，客户端和服务器之间如何根据客户端的需要发送适当的版本文档给客户端，比如同样在浏览器输入www.baidu.com，那么如果是英国的用户很可能希望收到的收到的是英语版本的网页，而在中国的用户很可能希望收到中文版本的网页，那么服务器是怎么实现根据需要发送不同的版本的呢！于是有了内容协商和转码！所谓内容协商指的是客户端和服务器通过在http报文设置相关首部来告诉对方自己需要什么、可以发送什么等，而转码则是把文档装成其他格式的文档，注意：转码和内容编码及传输编码不一样，后两者是更高层次上的编码！

相关术语

• 转码：有时根据客户端设备的不同，需要将资源转换成响应的格式的文件以让客户端设备更好的处理资源，这种类似的操作就称作转码。

内容协商技术

• 内容协商技术从实现方式来说有三种：

1、客户端驱动实现方式：客户端发起请求，服务器返回资源可用版本的列表，这种方式实现起来简单，但同时有个问题就是至少需要发送两次请求才能得到自己喜欢的响应（第一次获取列表，第二次才是得到资源），显然会造成时延、浪费带宽。

2、服务器驱动实现方式：这种方式由服务器通过检测客户端发送过来的内容协商首部来主动决定发送相应版本的资源，涉及到著名q值检测技术。这种方式的问题就是，如果客户端的发送过来的相关首部不明确的话，那么就得服务器自己去判断了。

客户端驱动的协商

• 这种方式实际上有两种方法为客户端提供选项：一是发送回一个html文档，里面有到该页面的各种版本的链接和每个版本的描述信息；另一种是发送回HTTP/1.1响应式，使用300 Multiple Choices响应代码。不管怎么样，决定权在客户端。这种方式除了增加时延并且对每个页面都要进行繁琐的多次请求之外，还有个缺点就是需要多个url,比如有个资源www.xxxx.com有英语版本好中文版本，那么在把页面分享给朋友的时候就是这种情况：www.xxx.com/en和www.xxx.com/ch。

服务器驱动的协商

• 我们知道客户端驱动的协商会增加额外的通信量，那么避免这种情况就是让服务器端主动决定发送什么给客户端。但是为了做到这一点，客户端必须发送有关客户偏好的足够信息。以便能够左春准确的决策。服务器通过客户端请求的首部集来获得这方面的信息。相关客户端可以发送给服务器做判断的首部如下：

1、Accept首部集

2、User-Agent

内容协商首部集

• Accept首部集和匹配的文档首部集

• 质量值：HTTP提供了一种机制，可以让使得客户端足以描述自己的偏好信息，这种机制就是质量值（简称q值）。

内容协商首部中的质量值

• http协议中定义了质量值，允许客户端为每种偏好类别列出多种选项，并为每种偏好选项关联了一个优先次序。例如，客户端可以发送下列形式的Accept-Language首部：

其中q值的范围从0.0~1.0（0.0是优先级最低的，而1.0是优先级最高的）。上面列出的那个首部，说明该客户端最愿意接收荷兰语（缩写为nl）文档，但英语（缩写为en）文档也行；无论如何，这个客户端都不愿意收到法语（缩写为fr）或土耳其语（缩写为tr）的版本。注意，偏好的排列顺序并不重要，只有与偏好相关的q值才是重要的。如果上面的列表中，服务器没有找到自己匹配的文档，那么服务器将会采取转码等修改文档方式来实现响应。

随其它首部集而变化

• Vary首部：这个首部告知缓存（还有客户端的和所有下游的代理）服务器根据哪些首部来决定发送响应的最佳版本。

透明协商

• 透明协商机制试图从服务器上去除服务器驱动协商所需的负载，并用中间代理来代表客户端以使与客户端的报文交换最小化。假定代理了解客户端的预期，这样就可以代表客户端与服务器协商（在客户端请求内容的时候，代理已经收到了客户端的预期）。为了支持透明内容协商，服务器必须有能力告知代理，服务器需要检查哪些请求首部，以便对客户端的请求进行最佳匹配。HTTP/1.1规范中没有定义任何透明协商机制，但定义了Vary首部。服务器在响应中发送了Vary首部，以告知中间节点需要使用哪些请求首部进行协商。涉及到的首部有Vary。

转码

• 如果服务器没有能满足客户端需求的文档会怎么样呢？服务器可以给出一个错误响应。但理论上，服务器可以把现存的文档转换成某种客户端可用的文档。这种选项称为转码。有三种类别的转码：格式转换、信息综合以及内容注入。

1、格式转换是指将数据从一种格式转换成另一种格式，使之可以被客户端查看。

2、信息综合是从文档中提取关键的信息片段称为信息综合。

此外，转码的替代做法是在web服务器上建立Web页面的不同副本，例如一个是HTML；一个是WML。但这种方式操作起来工程量大，一个小小的改动，所有的相关的页面都要更改，加大了存储空间等。