自定义 HTTP 标头:命名约定 [英] Custom HTTP headers : naming conventions

查看:48
本文介绍了自定义 HTTP 标头:命名约定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的一些用户要求我们将与其帐户相关的数据包含在我们发送给他们的请求的 HTTP 标头中,甚至是他们从我们的 API 获得的响应中.在命名格式...等方面,添加自定义 HTTP 标头的一般约定是什么?

此外,请随时发布您在网络上偶然发现的这些的任何巧妙用法;我们正在尝试使用最好的作为目标来实现这一点:)

解决方案

推荐 以X-"开头.例如.X-Forwarded-For, X-Requested-With.这在 a.o. 中也有提到.RFC 2047 的第 5 部分.


更新 1:2011 年 6 月,第一个 IETF 草案 已发布以弃用使用X-"的建议.非标准标头的前缀.原因是当非标准标头以X-"为前缀时,成为标准,删除X-"前缀破坏了向后兼容性,迫使应用程序协议支持这两个名称(例如,x-gzip & gzip 现在是等效的).因此,官方建议只是给它们命名合理,而不用X-".前缀.


更新 2:2012 年 6 月,建议弃用X-"前缀已成为正式的 RFC 6648.以下是相关的引用:

<块引用>

###3.给新参数创作者的建议

<块引用>

...

<块引用>

  1. 不应在其参数名称前加上X-";或类似构造.

<块引用>

###4.给协议设计者的建议

<块引用>

...

<块引用>

  1. 不应该禁止带有X-"的参数;前缀或类似构造从注册.

<块引用>

  1. 不得规定带有X-"的参数是前缀或类似的结构需要被理解为未标准化.

<块引用>

  1. 不得规定不带X-"的参数不带X-"前缀或类似的结构需要被理解为标准化.

注意不应该"(气馁") 与不得"不同.(禁止"),另请参阅 RFC 2119 以了解有关这些关键字的其他规范.换句话说,您可以继续使用X-"带前缀的标头,但官方不再推荐它,而且您绝对不会将它们记录为公共标准.


总结:

  • 官方建议只是合理地命名它们,而不使用X-".前缀
  • 您可以继续使用X-";带前缀的标头,但不再正式推荐它,您绝对不会将它们记录为公共标准

Several of our users have asked us to include data relative to their account in the HTTP headers of requests we send them, or even responses they get from our API. What is the general convention to add custom HTTP headers, in terms of naming, format... etc.

Also, feel free to post any smart usage of these that you stumbled upon on the web; We're trying to implement this using what's best out there as a target :)

解决方案

The recommendation is was to start their name with "X-". E.g. X-Forwarded-For, X-Requested-With. This is also mentioned in a.o. section 5 of RFC 2047.


Update 1: On June 2011, the first IETF draft was posted to deprecate the recommendation of using the "X-" prefix for non-standard headers. The reason is that when non-standard headers prefixed with "X-" become standard, removing the "X-" prefix breaks backwards compatibility, forcing application protocols to support both names (E.g, x-gzip & gzip are now equivalent). So, the official recommendation is to just name them sensibly without the "X-" prefix.


Update 2: On June 2012, the deprecation of recommendation to use the "X-" prefix has become official as RFC 6648. Below are cites of relevance:

###3. Recommendations for Creators of New Parameters

...

  1. SHOULD NOT prefix their parameter names with "X-" or similar constructs.

###4. Recommendations for Protocol Designers

...

  1. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered.

  1. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.

  1. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized.

Note that "SHOULD NOT" ("discouraged") is not the same as "MUST NOT" ("forbidden"), see also RFC 2119 for another spec on those keywords. In other words, you can keep using "X-" prefixed headers, but it's not officially recommended anymore and you may definitely not document them as if they are public standard.


Summary:

  • the official recommendation is to just name them sensibly without the "X-" prefix
  • you can keep using "X-" prefixed headers, but it's not officially recommended anymore and you may definitely not document them as if they are public standard

这篇关于自定义 HTTP 标头:命名约定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆