Custom HTTP headers : naming conventions
我们的一些用户要求我们在我们发送给他们的请求的HTTP头中包含与其帐户相关的数据，甚至包括他们从我们的API得到的响应。在命名、格式等方面，添加自定义HTTP头的一般约定是什么？等。
另外，请随意发布您在网上偶然发现的这些智能用法；我们正在尝试使用最好的方法作为目标来实现这一点：)
2012年6月，使用"x-"前缀的建议被否决，正式成为RFC 6648。以下是相关的引文：
3. Recommendations for Creators of New Parameters
...
SHOULD NOT prefix their parameter names with"X-" or similar
constructs.
4. Recommendations for Protocol Designers
...
SHOULD NOT prohibit parameters with an"X-" prefix or similar
constructs from being registered.MUST NOT stipulate that a parameter with an"X-" prefix or
similar constructs needs to be understood as unstandardized.MUST NOT stipulate that a parameter without an"X-" prefix or
similar constructs needs to be understood as standardized.
请注意，"不应"("不鼓励")与"不得"("禁止")不同，请参阅RFC 2119了解这些关键字的其他规范。换言之，您可以继续使用"x-"前缀头，但不建议这样做，而且您可能不会将它们作为公共标准来记录。
2011年6月，IETF发布了第一份草案，反对对非标准报头使用"x-"前缀的建议。原因是，当以"x-"为前缀的非标准头成为标准头时，删除"x-"前缀会破坏向后兼容性，迫使应用程序协议支持这两个名称(例如，
建议以"x-"开头。例如：
这个问题需要重读。所问的实际问题与CSS属性中的供应商前缀不同，在这里未来的校对和考虑供应商支持和官方标准是适当的。实际提出的问题更类似于选择URL查询参数名称。没有人应该关心他们是什么。但是，自定义的名称间距是一个完全有效的、常见的、正确的操作。
理论基础：这是关于开发人员之间关于定制的、特定于应用程序的头文件的约定——"与他们的帐户相关的数据"——这与第三方要实现的供应商、标准机构或协议没有任何关系，除非讨论中的开发人员只需要避免头文件名可能会被服务器、代理服务器或代理服务器使用。IES或客户。因此，给出的"x-gzip/gzip"和"x-forwarded/forwarded for"示例是没有意义的。提出的问题是关于私有API上下文中的约定，类似于URL查询参数命名约定。这是一个偏好和名称间距的问题；对于没有"x"的代理或供应商支持"x-clientdatafoo"的担忧显然放错了位置。
"x-"前缀没有什么特别或神奇的地方，但它有助于明确它是一个自定义头。事实上，RFC-6648等帮助支持使用"x-"前缀的情况，因为——作为HTTP客户机和服务器的供应商，放弃了前缀——您的应用程序特定的私有API，个人数据传递机制正变得更好地隔离名称空间与少量官方保留头名称的冲突。也就是说，我个人的偏好和建议是更进一步，比如"x-acme-clientdatafoo"(如果你的widget公司是"acme")。
imho IETF规范没有足够的具体性来回答OP的问题，因为它无法区分完全不同的用例：(a)供应商一方面引入了新的全球适用功能，如"转发给"，而(b)应用程序开发人员将应用程序特定的字符串传递给/从客户机和服务器传递。规范只涉及前者(a)。这里的问题是(b)是否有约定。有。它们包括按字母顺序将参数分组在一起，并将它们与(a)类型的许多标准相关的头文件分开。使用"x-"或"x-acme-"前缀对于(b)是方便和合法的，并且不与(a)冲突。供应商停止使用"x-"表示(a)的次数越多，则(b)的用法就越清晰。
例子：google(在各种标准机构中都有一点分量)截至今天，20141102在这篇对我的答案进行的简短编辑中，目前正在使用"x-mod-pagespeed"来表示参与转换给定响应的Apache模块的版本。有人真的建议谷歌使用"mod pagespeed"，而不使用"x-"，和/或要求IETF祝福它的使用吗？
总结：如果您在应用程序中使用自定义HTTP头(有时作为cookie的适当替代方法)来向服务器传递数据，并且这些头(明确地说，这些头)从来没有打算在应用程序上下文之外使用，则名称将它们与"x-"或"x-foo-"前缀隔开是一种合理且常见的约定。
HTTP头的格式在HTTP规范中定义。我将讨论HTTP 1.1，它的规范是RFC2616。在第4.2节"消息头"中，定义了头的一般结构：
1 2 3 4 5 6 | 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> |
这个定义基于两个主要支柱，令牌和文本。二者都在第2.2节"基本规则"中定义。令牌是：
1 | token = 1* |
依次依靠char、ctl和分隔符：
1 2 3 4 5 6 7 8 9 | CHAR = CTL = <any US-ASCII control character (octets 0 - 31) and DEL (127)> separators ="(" |")" |"<" |">" |"@" |"," |";" |":" |"" | <"> |"/" |"[" |"]" |"?" |"=" |"{" |"}" | SP | HT |
文本是：
1 2 | TEXT = <any OCTET except CTLs, but including LWS> |
其中lws是线性空白，其定义我不会复制，而octet是：
1 | OCTET = |
定义后附有注释：
1 2 3 4 5 | 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被视为控制字符)。此外，对文本生成的评论意味着八位字节将被解释为在ISO-8859-1中，并且存在一种编码机制(这是可怕的，顺便说一下)来表示该编码之外的字符。
因此，要特别响应@balusc，很明显根据规范，头值在iso-8859-1中。我在Tomcat的头中发送了high-8859-1字符(特别是一些法语中使用的重音元音)，并让火狐正确地解释了这些字符，因此在某种程度上，这在实践中和理论上都有效(尽管这是一个包含URL的位置头，而这些字符在URL中是不合法的，所以这实际上是非法，但根据不同的规则！).
也就是说，我不会依赖于在所有服务器、代理和客户机上工作的ISO-8859-1，所以我将坚持使用ASCII作为防御编程的一个问题。
修改或更准确地说，添加额外的HTTP头是一个很好的代码调试工具(如果没有其他的话)。
当URL请求返回重定向或图像时，没有HTML"page"可临时将调试代码的结果写入-至少没有浏览器中可见的结果。
一种方法是将数据写入本地日志文件，然后查看该文件。另一种方法是临时添加反映正在调试的数据和变量的HTTP头。
我经常添加额外的HTTP头，比如x-fubar-somevar:或者x-testing-someresult:来测试东西，并且发现了很多本来很难跟踪的错误。
头字段名称注册表是在rfc3864中定义的，并且"x-"没有特殊的地方。
据我所知，没有关于私有头的指导原则；如果有疑问，请避免使用它们。或者看看HTTP扩展框架(RFC2774)。
了解更多的用例会很有趣；为什么不能将信息添加到消息体中？
RFC6648建议您假设您的自定义头"可能会成为标准化的、公共的、通常部署的或在多个实现之间可用的。"因此，它建议不要在它前面加上"x-"或类似的构造。
但是，有一个例外，"当(您的头)极不可能被标准化时。"对于这种"特定于实现和私有使用"的头，RFC说，像供应商前缀这样的名称空间是合理的。