自定义HTTP标头：命名约定

我们的一些用户要求我们在我们发送给他们的http标头请求中包含与他们帐户相关的数据，甚至是他们从我们的API获得的响应。添加自定义HTTP标头的一般约定是什么，就命名、格式……等而言。

此外，请随时发布您在网络上偶然发现的这些智能用法；我们正在尝试使用最好的目标来实现这一点：）

506431 次浏览
小开
最佳答案

建议是是以“X-”开头。例如#0、#1。这也在a. o.中提到。rfc2047的第5节。

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

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

3.对新参数创建者的建议

…

  1. 不应该在参数名前加上“X-”或类似的前缀构造。

4.对协议设计者的建议

…

  1. 不应该禁止带有“X-”前缀或类似的参数#36825；注册

  2. 不得规定带有“X-”前缀的参数或类似的结构需要被理解为非标准化。

  3. 不得规定没有“X-”前缀的参数或类似的结构需要被理解为标准化。

请注意，“不应该”（“不鼓励”）与“不应该”（“禁止”）不同，有关这些关键字的另一个规范，请参阅rfc2119。换句话说，您可以继续使用“X-”前缀标头，但它不再被官方推荐，您绝对不能将它们记录为公共标准。

总结：

  • 官方建议只是将它们命名为明智地而没有“X-”前缀
  • 您可以继续使用“X-”前缀标题，但它不再是官方推荐的，您可能绝对不会将它们记录为公共标准
小开

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

据我所知，没有针对私有标头的指导方针；有疑问，请避免它们。或者看看HTTP扩展框架（rfc2774）。

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

小开

HTTP标头的格式在HTTP规范中定义。我要谈谈HTTP 1.1，其规范是rfc2616。在第4.2节“消息标头”中，定义了标头的一般结构：

   message-header = field-name ":" [ field-value ]field-name     = tokenfield-value    = *( field-content | LWS )field-content  = <the OCTETs making up the field-valueand consisting of either *TEXT or combinationsof 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           = <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 valuesthat are not intended to be interpreted by the message parser. Wordsof *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，这些字符在URL中是不合法的，所以这实际上是非法的，但根据不同的规则！）。

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

小开

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

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

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

我经常添加额外的HTTP标头，如X-fubar-Somevar：或X-testing-的一些结果：测试出来的东西，并发现了很多错误，否则很难跟踪。

小开

这个问题值得重读。实际提出的问题与CSS属性中的供应商前缀不同，在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”，而（B）应用程序开发人员在客户端和服务器之间传递特定于应用程序的字符串。规范只关心前者，（A）。这里的问题是（B）是否有约定。有。它们涉及按字母顺序将参数分组在一起，并将它们与许多与标准相关的类型（A）标头分开。使用“X-”或“X-ACME-”前缀对（B）来说是方便合法的，并且与（A）不冲突。供应商停止对（A）使用“X-”的次数越多，（B）就会变得越清晰。

示例：
Google（在各种标准机构中占有一席之地）-截至今天，20141102在对我的答案的这个轻微编辑中-目前使用“X-Mod-Pagespeed”来指示他们参与转换给定响应的Apache模块的版本。有人真的建议Google应该使用“Mod-Pagespeed”，没有“X-”，和/或要求IETF祝福它的使用吗？

总结：
如果您在应用程序中使用自定义HTTP标头（作为cookie的有时合适的替代方案）来向/从服务器传递数据，并且这些标头明确地不打算在应用程序的上下文之外使用，那么使用“X-”或“X-FOO-”前缀命名它们的行间距是合理且常见的约定。

小开

RFC6648建议您假设您的自定义标头“可能会变得标准化、公共、通用部署或可用于多个实现。”因此，它建议不要用“X-”或类似结构作为前缀。

但是，有一个例外，“当[您的标头]极不可能被标准化时”。对于这种“特定于实现和私人使用”的标头，RFC表示诸如供应商前缀之类的命名空间是合理的。


提交答案