“Accept-Language”头字段可以被用户代理发送以表明响应中首选的自然语言集合。语言标签被定义在3.1.3.1节。

     Accept-Language = 1#( language-range [ weight ] )
     language-range  =
               <language-range, see [RFC4647], Section 2.1>

每个language-range可以被给与一个关联的质量值以表示用户对由该范围指定的语言首选的评估，如5.3.1节定义。例如，

     Accept-Language: da, en-gb;q=0.8, en;q=0.7

表示：“我首选丹麦语，但也接受英式英语和其他类型的英语。”

没有任何Accept-Language头字段的请求暗示用户代理将在响应中接受任何语言。如果这个头字段在请求中出现并且响应的可用表示都不匹配语言标签，源服务器可以通过就像没有进行内容协商一样对待响应来忽略头字段或者遵循头字段而发送一个406（不可接受）响应。然而，后者不被鼓励，因为这么做可能阻止用户访问他们可能能够使用的内容（例如，在翻译软件的帮助下）。

注意，一些接收者将列出的语言标签的顺序是为一种降序优先的指示，特别是对于被分配相同质量值（没有任何值与q=1相同）的标签。然而，这个行为不能被依赖。为了一致和最大化互操作性，许多用户代理给每个语言标签分配一个独一无二的质量值，也按质量降序列出他们。关于语言优先级列表的额外讨论可以在RFC4647的2.3节中找到。

为了对应，RFC4647第3节定义了几个匹配方案。实现可以为他们的要求提供最合适的匹配方案。“基本过滤”方案（RFC4637，3.3.1节）与先前定义在RFC2616中14.4节中的匹配方案相同。在每个请求中发送一个具有用户完整语言偏好的Accept-Language头域（见第9.7节），可能会违背用户的隐私期望。

由于可理解性高度依赖于个人用户，用户代理需要允许用户通过语言偏好进行控制（通过用户代理自身的配置或通过用户可配置的默认系统设置）。没有为用户提供这中控制的用户代理不得发送Accept-Language头字段。

注意：在设置优先级的时候，用户代理应该为用户提供指导，因为用户很少熟悉上面描述的语言匹配的细节。例如，用户可能假定选择“en-gb”时，如果英式英语不可用，他们将被其他种类的英语文档服务。用户代理可能建议在这样的情况下，添加“en”到列表中以进行更好的匹配行为。