HTTP头的格式在HTTP规范中定义。我将讨论HTTP 1.1，其规范为RFC 2616。在第4.2节“消息头”中，定义了头的一般结构：

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

这一定义基于两个主要支柱，即token和TEXT。第2.2节“基本规则”中对两者进行了定义。令牌为：

   token          = 1*<any CHAR except CTLs or separators>

依次依靠CHAR、CTL和分离器：

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

文本为：

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

其中LWS是线性空白空间，其定义i不会再现，OCET是：

   OCTET          = <any 8-bit sequence of data>

定义附带注释：

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

因此，有两个结论。首先，很明显，标题名必须由ASCII字符的子集组成——字母数字、一些标点符号，而不是很多其他字符。其次，标头值的定义中没有任何内容将其限制为ASCII或排除8位字符：它明确由八位字节组成，仅禁止控制字符（请注意，CR和LF被视为控制）。此外，对TEXT生成的评论意味着八位字节将被解释为ISO-8859-1中的八位字节，并且存在一种编码机制（顺便说一句，这很可怕）来表示该编码之外的字符。

因此，为了特别回应@BalusC，很明显，根据规范，标头值在ISO-8859-1中。我在Tomcat的头中发送了高8859-1个字符（特别是法语中使用的一些重音元音），并让Firefox正确解释它们，因此在某种程度上，这在实践中和理论上都有效（尽管这是一个包含URL的Location头，这些字符在URL中是不合法的，所以这实际上是非法的，但根据不同的规则！）。

也就是说，我不会依赖ISO-8859-1在所有服务器、代理和客户端上工作，所以我会坚持使用ASCII作为防御性编程。

头字段名注册表在RFC3864中定义，“X-”没有什么特别之处。

据我所知，对于私有标头没有任何指导原则；如果有疑问，请避开它们。或者看看HTTP扩展框架（RFC 2774）。

了解更多的用例会很有趣；为什么不能将信息添加到消息正文中？

HTTP头的格式在HTTP规范中定义。我将讨论HTTP 1.1，其规范为RFC 2616。在第4.2节“消息头”中，定义了头的一般结构：

   message-header = field-name ":" [ field-value ]
   field-name     = token
   field-value    = *( field-content | LWS )
   field-content  = <the OCTETs making up the field-value
                    and consisting of either *TEXT or combinations
                    of token, separators, and quoted-string>

这一定义基于两个主要支柱，即token和TEXT。第2.2节“基本规则”中对两者进行了定义。令牌为：

   token          = 1*<any CHAR except CTLs or separators>

依次依靠CHAR、CTL和分离器：

   CHAR           = <any US-ASCII character (octets 0 - 127)>

   CTL            = <any US-ASCII control character
                    (octets 0 - 31) and DEL (127)>

   separators     = "(" | ")" | "<" | ">" | "@"
                  | "," | ";" | ":" | "\" | <">
                  | "/" | "[" | "]" | "?" | "="
                  | "{" | "}" | SP | HT

文本为：

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

其中LWS是线性空白空间，其定义i不会再现，OCET是：

   OCTET          = <any 8-bit sequence of data>

定义附带注释：

The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

因此，有两个结论。首先，很明显，标题名必须由ASCII字符的子集组成——字母数字、一些标点符号，而不是很多其他字符。其次，标头值的定义中没有任何内容将其限制为ASCII或排除8位字符：它明确由八位字节组成，仅禁止控制字符（请注意，CR和LF被视为控制）。此外，对TEXT生成的评论意味着八位字节将被解释为ISO-8859-1中的八位字节，并且存在一种编码机制（顺便说一句，这很可怕）来表示该编码之外的字符。

因此，为了特别回应@BalusC，很明显，根据规范，标头值在ISO-8859-1中。我在Tomcat的头中发送了高8859-1个字符（特别是法语中使用的一些重音元音），并让Firefox正确解释它们，因此在某种程度上，这在实践中和理论上都有效（尽管这是一个包含URL的Location头，这些字符在URL中是不合法的，所以这实际上是非法的，但根据不同的规则！）。

也就是说，我不会依赖ISO-8859-1在所有服务器、代理和客户端上工作，所以我会坚持使用ASCII作为防御性编程。

修改，或者更正确地说，添加额外的HTTP头是一个很棒的代码调试工具。

当URL请求返回重定向或图像时，没有html“页面”可以临时写入调试代码的结果，至少在浏览器中不可见。

一种方法是将数据写入本地日志文件，稍后查看该文件。另一种方法是临时添加反映正在调试的数据和变量的HTTP标头。

我经常添加额外的HTTP标头，如X-fubar-somevar:或X-testing-someresult:，以测试结果，并发现了很多错误，否则很难跟踪。

建议以“X-”开头。例如，X-Forwarded-For、X-Requested-With。RFC 2047的a.o.第5节也提到了这一点。

更新1:2011年6月，发布了第一份IETF草案，反对对非标准标题使用“X-”前缀的建议。原因是，当前缀为“X-”的非标准标头成为标准时，删除“X-”前缀会破坏向后兼容性，迫使应用程序协议同时支持这两个名称（例如，X-gzip和gzip现在是等效的）。因此，官方建议只是合理地命名它们，而不使用“X-”前缀。

更新2:2012年6月，反对使用“X-”前缀的建议已正式成为RFC 6648。以下是相关引用：

3.对新参数创建者的建议...不应在参数名称前加上“X-”或类似的前缀构造。

4.对协议设计者的建议...不应禁止带有“X-”前缀或类似前缀的参数构造被注册。不得规定带有“X-”前缀的参数或类似的构造需要被理解为非标准化的。不得规定没有“X-”前缀的参数或类似的构造需要被理解为标准化的。

请注意，“不应该”（“不鼓励”）与“禁止”（“禁止”）不同，有关这些关键字的另一个规范，请参阅RFC 2119。换句话说，您可以继续使用前缀为“X”的标头，但官方不再建议使用它，而且您可能肯定不会将它们作为公共标准进行记录。

摘要：

官方的建议是不加“X-”前缀，只合理地命名它们您可以继续使用带有“X”前缀的标题，但官方不再建议使用它，而且您可能不会将它们作为公共标准进行记录

这个问题值得重新阅读。实际提出的问题与CSS财产中的供应商前缀不同，在CSS属性中，考虑供应商支持和官方标准是合适的。所问的实际问题更类似于选择URL查询参数名称。没有人应该关心它们是什么。但是，自定义名称间距是一个非常有效的、常见的、正确的做法。

理论基础：这是关于开发人员之间关于自定义的、特定于应用程序的头的约定——“与他们的帐户相关的数据”——这与供应商、标准机构或由第三方实现的协议无关，只是所讨论的开发人员只需避免服务器、代理或客户端可能有其他用途的头名称。因此，给出的“X-Gzip/Gzip”和“X-Forwarded-For/Forwarded-For”示例没有意义。提出的问题是关于私有API上下文中的约定，类似于URL查询参数命名约定。这是一个偏好和名字间距的问题；关于“X-ClientDataFoo”被任何没有“X”的代理或供应商支持的担忧显然是错误的。

“X-”前缀没有什么特别或神奇之处，但它有助于明确它是一个自定义标头。事实上，RFC-6648等有助于支持使用“X-”前缀的理由，因为随着HTTP客户端和服务器的供应商放弃前缀，您的特定于应用程序的私有API和个人数据传递机制正变得更好地防止与少量官方保留头名称的名称空间冲突。也就是说，我个人的偏好和建议是更进一步，比如“X-ACME-ClientDataFoo”（如果你的小部件公司是“ACME”）。

IMHO IETF规范不够具体，无法回答OP的问题，因为它无法区分完全不同的用例：（A）一方面，供应商引入了新的全球适用功能，如“Forwarded For”，另一方面，（B）应用程序开发人员向客户端和服务器传递应用程序特定的字符串。规范只涉及前者（A）。这里的问题是（B）是否有约定。有。它们涉及按字母顺序将参数分组在一起，并将它们与类型（A）的许多标准相关标头分开。使用“X-”或“X-ACME-”前缀对于（B）是方便和合法的，并且与（A）不冲突。越多的供应商停止为（A）使用“X-”，（B）的供应商将变得越清晰。

例子：谷歌（在各种标准机构中占有一定的权重）目前正在使用“X-Mod-Pagespeed”来表示其Apache模块的版本，该模块涉及转换给定响应。有人真的建议谷歌使用“Mod Pagespeed”，而不使用“X-”，和/或请IETF支持它的使用吗？

摘要：如果您在应用程序中使用自定义HTTP头（有时是cookie的适当替代品）来向服务器传递数据，并且这些头明确不打算在应用程序上下文之外使用，则使用“X-”或“X-FOO-”前缀将它们隔开是合理且常见的约定。