头字段是键值对的，这可以被用于传递于消息，它的负载，目标资源或连接的相关数据（即，控制数据）。查看RFC7230的3.2节了解HTTP消息中的通用头字段定义。

    头字段名称的要求定义在BCP90。

    定义新字段的规范的作者被建议保持名字尽可能的短，并且不要使用“X-”的名称前缀，除非头字段不会被用于互联网。（“X-”前缀用法已经在事件中被广泛滥用；它本来只打算被用作一个避免在专有软件或内网处理中的名称碰撞机制，因为这个前缀将保证私有名字不会和新注册的互联网名字发生碰撞，查看BCP178了解进一步信息 ）。

    新头字段值一般有他们的语法，使用ABNF（RFC5234）定义，使用RFC7230的第7节的扩展定义，并且通常被限制在US-ASCCI字符的范围内。需要一个更大字符范围的头字段可以使用一个编码，如RFC5987中定义。

    在原始字段值中的前导和后导空白在字段解析时被移除（RFC7230，3.2.4节）。字段定义中值的前导或尾随空格是重要的，必须使用容器语法，如引号字符串（RFC7230，3.2.6节）。

    因为逗号（“,”）被用作字段值之间的通用分隔符，如果在字段值中出现，他们需要被谨慎对待。通常，可能包含逗号的组件使用双引号字符ABNF产生式的双引号进行保护。

    例如，一个文本日期和一个URI（他们都可能包含一个逗号）可以像这样安全的带入字段值：

    1.      Example-URI-Field: "http://example.com/a.html,foo",
    2.                         "http://without-a-comma.example.com/"
    3.      Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"

    注意双引号分隔符几乎总是以双引字符串产生式的形式被使用；在双引号内使用一个不同的语法可能造成不必要的混乱。

    很多头字段使用一个包含不区分大小写的名称参数（例如，3.1.1.5节定义的Content-Type）的格式。允许参数值无引号（记号）和有引号(引号字符)语法能使接收者使用已有的解析器组件。当允许两种形式时，参数值的含义应该与使用它的语法独立（作为一个例子，查看3.1.1.1节中媒体类型参数处理的注意）。

    定义新头字段的规范的作者被建议考虑文档化：

    • 字段值是单个值还是可以是一个列表（由逗号分隔；查看RFC7230，3.2节）

      如果他没有使用列表语法，文档如何对待字段值发生多次的消息（一个明智的默认将忽略字段值，但这可能不会总是正确的选择）。

      注意中介和软件库可能组合多个头字段实例为一个，而不管字段的定义不允许列表语法。一个健全的格式能使接收者发现这种情况（良好的例子：“Content-Type”，因为都喊只可以在引号内出现；不好的例子：”Location“，因为逗号可能出现在URI内）。

    • 在什么情况下头字段可以被使用；例如，只能在请求或响应中，在所有消息中，旨在对特定请求方法的响应中等。

    • 在PUT请求中，理解它的源服务器是否应该存储它。

    • 字段语义是否被上下文进一步重定义，如被现有的请求方法或状态码。

    • 在Connection头字段中列出字段名是否合适（即，如果头字段是逐跳的；查看RFC7230，6.1节）。

    • 在什么情况下中介被允许插入，删除或修改字段值。

    • 在Vary响应头字段中列出字段名是否合适（例如，当请求头字段被源服务器的内容选择算法使用的时候；查看7.1.4节）。

    • 头字段在trailers中是否有用或被许可（查看RFC7230，4.1节）。

    • 头字段是否应该保留在重定向当中。

    • 它是否采用任何额外的安全注意事项，如隐私相关数据的泄露。