我们的一些用户要求我们在我们发送给他们的请求的 HTTP 标头 中包含与他们的帐户相关的数据,甚至是他们从我们的 API 获得的响应。 在命名 、 格式 等方面,添加自定义 HTTP 标头的一般约定是什么?
此外,请随时发布您在网络上偶然发现的任何智能用法;我们正在尝试使用最好的目标来实现这一点:)
建议 是以 “X-”开头的名字 。 例如X-Forwarded- For,X-Requested- With。这也在RFC 2047的第 5 节中提到。
X-Forwarded- For
X-Requested- With
更新 1 :2011 年 6 月,发布了第一个IETF 草案,以 弃用 对非标准标头使用“X-”前缀的建议。原因是当以“X-”为前缀的非标准标头成为标准时,删除“X-”前缀会破坏向后兼容性,迫使应用程序协议支持这两个名称(例如,x-gzip&gzip现在是等效的)。因此,官方的建议是 合理地 命名它们,不要使用“X-”前缀。
x-gzip
gzip
更新 2 :2012 年 6 月,弃用使用“X-”前缀的建议已正式成为RFC 6648。以下是相关引用:
3. 对新参数创作者的建议 … 不应在其参数名称前加上“X-”或类似结构。 4. 对协议设计者的建议 … 不应禁止注册带有“X-”前缀或类似结构的参数。 不得规定带有“X-”前缀或类似结构的参数需要被理解为非标准化的。 不得规定没有“X-”前缀或类似结构的参数需要被理解为标准化。
…
不应禁止注册带有“X-”前缀或类似结构的参数。
不得规定带有“X-”前缀或类似结构的参数需要被理解为非标准化的。
不得规定没有“X-”前缀或类似结构的参数需要被理解为标准化。
请注意,“不应该”(“不鼓励”)与“不得”(“禁止”)不同,有关这些关键字的另一个规范,另请参见RFC 2119。换句话说,您可以继续使用以“X-”为前缀的标头,但它不再是官方推荐的,您可能绝对不会将它们记录为公共标准。
摘要 :