自定义HTTP头:命名约定

是 X-Forwarded-For , X-Requested-With . 这一点也在a.o.第5节中提到 RFC 2047 .

:2011年6月1日 IETF draft 已发布到 贬损 建议对非标准头使用“X-”前缀。原因是,当前缀为“X-”的非标准头成为标准头时,删除“X-”前缀会破坏向后兼容性,迫使应用程序协议同时支持这两个名称(例如, x-gzip gzip 现在是等价的)。所以,官方的建议是只说出他们的名字 明智地 没有“X-”前缀。

:2012年6月,反对使用“X-”前缀的建议正式成为 RFC 6648 . 以下是相关引用:

三。对新参数创造者的建议

...

3. 不应在其参数名称前面加上“X-”或类似的前缀 构造。

4对协议设计者的建议

...

4. 阻止注册。

5. 类似的构造需要理解为非标准化的。

6. 不能规定没有“X-”前缀的参数或

请注意,“不应”(“劝阻”)与“不得”(“禁止”)不同,另请参见 RFC 2119 关于这些关键字的另一个规范。换句话说,您可以继续使用前缀为“X-”的标题,但它不再是官方推荐的,而且您可能肯定不会将它们作为公共标准来记录。

:

• 明智地

这个问题值得重读。提出的实际问题与CSS属性中的供应商前缀不同,在CSS属性中,对供应商支持和官方标准的未来验证和思考是合适的。实际问题更类似于选择URL查询参数名。没有人应该关心他们是什么。但是,将自定义的名称分隔开来是一种完全有效的、常见的、正确的做法。

理论基础:
开发人员之间对于自定义的、特定于应用程序的头的约定 -- " 与账户相关的数据 “--与供应商、标准机构或由第三方实现的协议无关,只是所讨论的开发人员只需避免可能由服务器、代理或客户端具有其他预期用途的头名称。因此,给出的“X-Gzip/Gzip”和“X-Forwarded-For/Forwarded-For”示例没有实际意义。提出的问题是关于私有API上下文中的约定,类似于URL查询参数命名约定。这是一个偏好和名称间距的问题;关于“X-ClientDataFoo”被任何代理或供应商支持而没有“X”的担忧显然是错误的。

“X-”前缀没有什么特别或神奇的地方,但它有助于明确它是一个自定义头。事实上,RFC-6648等有助于支持使用“X-”前缀的理由,因为——随着HTTP客户端和服务器的供应商放弃前缀——你的应用程序特定的私有API,个人数据传递机制正在变得更加不受名称空间与少量官方保留头名称的冲突的影响。也就是说,我个人的偏好和建议是更进一步,比如“X-ACME-ClientDataFoo”(如果你的widget公司是“ACME”)。

谷歌(在各个标准机构中占有一席之地)目前正在使用“X-Mod-Pagespeed”来表示转换给定响应所涉及的Apache模块的版本。有人真的建议谷歌应该使用“Mod Pagespeed”,而不使用“X-”,和/或要求IETF支持它的使用吗?

如果您在应用程序中使用自定义HTTP头(有时是cookies的适当替代方法)向服务器传递数据或从服务器传递数据,并且这些头明确地不打算在应用程序上下文之外使用,那么使用“X-”或“X-FOO-”前缀来分隔它们是一种合理且常见的约定。

HTTP头的格式在HTTP规范中定义。我将讨论HTTP1.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>

   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>

   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].

所以,有两个结论。首先,很明显 名称 必须由ASCII字符的子集组成-字母数字,一些标点符号,而不是很多其他字符。其次,标题的定义中没有任何内容 价值 这将它限制为ASCII或排除8位字符:它显式地由八位字节组成,只有控制字符被禁止(注意,CR和LF被认为是控制字符)。此外,对文本生成的评论意味着八位字节将被解释为在ISO-8859-1中,并且存在一种编码机制(顺便说一句,这是可怕的)来表示编码之外的字符。

因此,特别是对@BalusC的响应,很明显,根据规范,标题值在ISO-8859-1中。我在Tomcat的头中发送了高8859-1字符(特别是法语中使用的一些重音元音),Firefox对它们进行了正确的解释,因此在某种程度上,这在实践中和理论上都是有效的(虽然这是一个位置头,其中包含一个URL,而且这些字符在URL中是不合法的,所以这实际上是错误的不合法,但根据不同的规则!)。

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

RFC6648 建议您假设您的自定义头“可能成为标准化的、公共的、通常部署的或跨多个实现可用的”。因此,建议不要使用“X-”或类似的构造作为前缀。

然而,有一个例外是“当[你的头]极不可能被标准化的时候。”对于这种“特定于实现和私有使用”的头,RFC说像供应商前缀这样的名称空间是合理的。

或者更准确地说, 额外的HTTP头是一个伟大的代码调试工具,如果没有别的。

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

我经常添加额外的HTTP头文件,比如X-fubar-somevar:或X-testing-someresult:来进行测试,并且发现了很多本来很难追踪的bug。

RFC3864 “X-”也没什么特别的。

据我所知,没有关于私有头的准则;毫无疑问,应该避免使用它们。或者看看HTTP扩展框架( RFC 2774 ).