当内容协商的优先级被用户代理在请求中发送以鼓励服务器使用一个算法来选择更好的表示时，把它称作主动协商（又称作，服务器驱动协商）。与请求中提供的各种信息相比，选择是基于可用的响应表示（响应可能会发生变化的尺寸，例如语言，内容编码等），包括5.3节的显式协商字段和隐式 特征，例如客户端的网络地址或User-Agent字段的一部分。

当从可用表示中进行选择的算法难以描述用户代理的时候，或者当服务器希望在一个响应中发送它“猜测的最好的结果”给客户端（希望如果”猜测的最好的结果“能够满足用户可以子请求的往返延迟），主动协商显得有利。为了提高服务器的猜测，用户代理可能发送描述它的优先级的头字段。

主动协商有一些严重的缺陷：

• ​ 对于任何给定的用户，服务器不可能准确的确定哪种表示可能是”最好的“，因为那需要完整的了解用户代理的能力和响应的目标用途（例如，用户想要在屏幕上观看它还是将它打印到纸上？）。
• 让用户代理在每个请求中描述它的功能非常低效（只有一小部分响应有多个表示）并且存在潜在的用户隐私风险。
• 它让源服务器和生成响应的算法变得复杂；并且
• 它限制了共享缓存对响应的重复利用。

用户代理不能依赖主动协商首选项，因为源服务器可能没有对所有请求的资源实现主动协商，或者决定发送一个响应与用户代理的优先级不匹配的响应比发送一个406（不可接受）响应要好。

Vary头字段（7.1.4节）经常在响应主体中被发送来回应主动协商以指明请求信息的哪个部分被用于选择算法。