HTTP 内容协商

大多数 HTTP 响应都包含一个实体，其中包含供用户解释的信息。通常，它用于为用户提供与请求对应的最佳可用实体。不幸的是，对于缓存和服务器而言，并非所有用户对什么是最佳的都有相同的偏好。这就是为什么 HTTP 具有多种“内容协商”机制的原因。当有多个表示形式可用时，选择给定响应的最佳表示形式的过程。

任何包含实体主体的响应都可能需要协商，包括错误响应。

在 HTTP 中，有两种类型的内容协商：服务器驱动的协商和代理驱动的协商。这两种协商都是正交的，因此可以组合使用或单独使用。一种组合方法称为透明协商，当原始服务器提供代理驱动协商的信息时，缓存使用这些信息为后续请求提供服务器驱动的协商。

服务器驱动的协商

当发生服务器驱动的协商时，响应的最佳表示形式的选择由位于服务器上的算法进行。基于资源的可用表示形式进行选择，以及内容。选择还基于请求消息中特定标头字段的内容或有关请求的其他信息（例如客户端的网络地址）。

优点

1. 当从可用表示形式中进行选择的算法难以向用户代理描述时，这很有用。
2. 当服务器希望将它的“最佳猜测”与第一个响应一起发送给客户端时，这很有用。
3. 为了改进服务器的猜测，用户代理可以包括描述其对此类响应的偏好的请求标头字段。

缺点

1. 对于服务器而言，准确确定什么对任何给定用户来说是最佳的，是不可能的。这就是为什么服务器需要完全了解用户代理的功能以及响应的预期用途。
2. 它使原始服务器的实现以及生成对请求的响应的算法复杂化。

代理驱动的协商

当发生代理驱动的协商时，用户代理在从原始服务器收到初始响应后，执行响应的最佳表示形式的选择。在代理驱动的协商中，选择基于响应的可用表示形式的列表，该列表包含在初始响应的标头字段或实体主体中，每个表示形式都由其自己的 URI 标识。可以由用户从生成的菜单中手动选择，也可以自动执行从表示形式列表中的选择。

优点

1. 当响应在常用维度上发生变化时，或者当原始服务器无法通过检查请求来确定用户代理的功能时，使用此方法。
2. 当公共缓存分配服务器负载并减少网络使用时，可以使用此方法。

缺点

代理驱动的协商在需要第二个请求才能获得最佳备用表示形式时会受到影响。

透明协商

它是服务器驱动的协商和代理驱动的协商的组合。如果以响应的可用表示形式列表的形式提供缓存，并且缓存完全理解变量的维度，则缓存将能够代表原始服务器执行服务器驱动的协商。