我们的一些用户要求我们在我们发送的请求的 HTTP标头中包含与其帐户相关的数据，甚至是我们从API获得的响应。 在命名，格式等方面添加自定义HTTP标头的一般惯例是什么。
另外，请随意发布您在网上偶然发现的这些智能用法;我们正在尝试使用最好的目标来实现这一目标：）
答案 0 :(得分：1040)
2012年6月，对使用“X-”前缀的建议的弃用已正式成为RFC 6648。以下是相关的引用：
3。新参数创建者的建议
...
- 不应在参数名称前加“X-”或类似名称 构建体。
4。协议设计者的建议
...
不应禁止带有“X-”前缀或类似参数的参数 构建来自注册。
不得规定带有“X-”前缀的参数或 类似的结构需要被理解为不标准化。
不得规定没有“X-”前缀的参数或 类似的结构需要被理解为标准化。
请注意，“不应该”（“不鼓励”）与“绝不”（“禁止”）不同，另请参阅RFC 2119以获取有关这些关键字的其他规范。换句话说，您可以继续使用“X-”前缀标题，但不建议这样做，您也不能将它们记录为公共标准。
2011年6月，第一个IETF draft被发布到弃用，建议对非标准标头使用“X-”前缀。原因是当前缀为“X-”的非标准头文件成为标准时，删除“X-”前缀会破坏向后兼容性，迫使应用程序协议支持这两个名称（例如，x-gzip＆amp; {{1}现在是等价的）。所以，建议只是在没有“X-”前缀的情况下将它们命名为 。
建议是 是以“X-”开始他们的名字。例如。 X-Forwarded-For，X-Requested-With。这也在a.o中提到。 RFC 2047的第5部分。
答案 1 :(得分：485)
这个问题需要重新阅读。所提出的实际问题与CSS属性中的供应商前缀不同，后者在未来的情况下以及对供应商支持和官方标准的考虑是合适的。问的实际问题更类似于选择URL查询参数名称。没有人应该关心它们是什么。但是，自定义名称间隔是完全有效的 - 并且是常见且正确的 - 要做的事情。
<强>理由：
它是开发人员之间关于自定义，特定于应用程序的标题 - “与其帐户相关的数据”的约定 - 与供应商，标准组织或由第三方实施的协议，除了有问题的开发人员只需要避免服务器，代理或客户端可能具有其他预期用途的头名称。出于这个原因，给出的“X-Gzip / Gzip”和“X-Forwarded-For / Forwarded-For”示例没有实际意义。提出的问题是关于私有API上下文中的约定，类似于URL查询参数命名约定。这是一个偏好和名称间距的问题;没有“X”的任何代理或供应商支持“X-ClientDataFoo”的担忧显然是错误的。
“X-”前缀没什么特别或神奇之处，但它有助于明确它是一个自定义标题。实际上，RFC-6648等帮助支持使用“X-”前缀的情况，因为 - 当HTTP客户端和服务器的供应商放弃前缀 - 您的应用程序特定的私有API，个人数据 - 传递机制变得更加绝对 - 与少量官方保留标题名称的名称空间冲突隔离。也就是说，我个人的偏好和建议是更进一步，例如“X-ACME-ClientDataFoo”（如果您的小部件公司是“ACME”）。
恕我直言，IETF规范没有足够具体来回答OP的问题，因为它无法区分完全不同的用例：（A）供应商一方面引入新的全球适用功能，如“Forwarded-For”，vs. （B）应用程序开发人员将特定于应用程序的字符串传递给客户端和服务器。该规范仅涉及前者（A）。这里的问题是（B）是否有惯例。有。它们涉及按字母顺序将参数分组，并将它们与（A）类型的许多标准相关标题分开。使用“X-”或“X-ACME-”前缀对于（B）来说是方便和合法的，并且与（A）不冲突。越多的供应商停止使用“X-”代表（A），（B）将变得更加清晰 - 不同。 示例：
谷歌（在各种标准机构中占有一定的份量）是 - 截至今日，20141102，在我的回答的这个轻微编辑中 - 目前正在使用“X-Mod-Pagespeed”来表示其所涉及的Apache模块的版本转换给定的响应。是否有人真的建议谷歌应该使用“Mod-Pagespeed”而不使用“X-”，和/或要求IETF保佑其使用？
摘要：
如果您在应用程序中使用自定义HTTP标头（作为有时适合的cookie替代方案）来向服务器传送数据或从服务器传递数据，并且这些标头明确地不打算在应用程序的上下文之外使用，用“X-”或“X-FOO-”前缀命名它们是一种合理且常见的约定。
答案 2 :(得分：61)
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>
这个定义依赖于两个主要支柱：令牌和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是：
TEXT = <any OCTET except CTLs,
but including LWS>
LWS是线性空格，其定义我不会重现，而OCTET是：
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].
所以，有两个结论。首先，显然标题 name 必须由ASCII字符的子集组成 - 字母数字，一些标点符号，而不是其他许多字符串。其次，标题值的定义中没有任何内容将其限制为ASCII或排除8位字符：它显式由八位字节组成，仅禁止控制字符（注意CR和LF被认为是控制）。此外，对TEXT产生的评论意味着八位字节将被解释为ISO-8859-1，并且存在一种编码机制（这是偶然的，非常可怕），用于表示编码之外的字符。
因此，特别要回应@BalusC，很明显根据规范，标题值在ISO-8859-1中。我已经在Tomcat的标题中发送了高8859-1个字符（特别是法语中使用的一些重音元音），并且让它们被Firefox正确解释，所以在某种程度上，这在实践和理论上都有效。 （虽然这是一个包含URL的Location标头，这些字符在URL中不合法，所以这实际上是非法的，但是在不同的规则下！）。
那就是说，我不会依赖ISO-8859-1在所有服务器，代理和客户端上工作，所以我会坚持使用ASCII作为防御性编程的问题。
答案 3 :(得分：16)
标题字段名称注册表在RFC3864中定义，“X - ”没有什么特别之处。
据我所知，私人标题没有指引;有疑问，避免它们。或者查看HTTP扩展框架（RFC 2774）。
了解更多用例会很有趣;为什么不能将信息添加到邮件正文中？
答案 4 :(得分：16)
修改或更正确地添加其他HTTP标头是一个很好的代码调试工具，如果没有别的。
当URL请求返回重定向或图像时，没有html“page”暂时将调试代码的结果写入 - 至少不是浏览器中可见的那个。
一种方法是将数据写入本地日志文件并稍后查看该文件。另一种方法是临时添加反映正在调试的数据和变量的HTTP头。
我经常添加额外的HTTP标头，例如X-fubar-somevar：或X-testing-someresult：测试出来的东西 - 并且发现了许多本来很难追踪的错误。
答案 5 :(得分：12)
RFC6648建议您假设自定义标头“可能会标准化，公开，普遍部署或在多个实现中可用”。因此，建议不要在其前面加上“ X-”或类似的结构。
但是，有一个例外“当[您的标头]极不可能被标准化时”。对于此类“特定于实现和私有使用”的标头，RFC表示有合理的名称空间（例如供应商前缀）。