自定义HTTP标头：命名约定-Java 学习之路

903

我们的一些用户要求我们在我们发送请求的HTTP标头中包含与其帐户相关的数据，甚至是我们从API获得的响应 . 根据 naming ， format 等添加自定义HTTP标头的一般惯例是什么？

另外，您可以随意发布您在网上偶然发现的任何智能用途;我们正在尝试使用最好的目标来实现这一目标:)

6 回答

57

这个问题需要重新阅读 . 问题的实际问题与CSS属性中的供应商前缀不同，后者在未来的情况下考虑供应商支持和官方标准 . 问的实际问题更类似于选择URL查询参数名称 . 没有人应该关心它们是什么 . 但是，自定义名称间距是完全有效的 - 并且是常见且正确的 - 要做的事情 .

Rationale:
它是关于开发人员对自定义，特定于应用程序的 Headers 的约定 - “与他们的帐户相关的数据" -- which have nothing to do with vendors, standards bodies, or protocols to be implemented by third parties, except that the developer in question simply needs to avoid header names that may have other intended use by servers, proxies or clients. For this reason, the " X-Gzip / Gzip " and " X-Forwarded-For / Forwarded-For " examples given are moot. The question posed is about conventions in the context of a private API, akin to URL query parameter naming conventions. It's a matter of preference and name-spacing; concerns about " X-ClientDataFoo " being supported by any proxy or vendor without the " X”显然是错位的 .

关于“X-”前缀没有什么特别或神奇之处，但它有助于明确它是一个自定义 Headers . 事实上，RFC-6648等帮助支持使用“X-”前缀的情况，因为 - 当HTTP客户端和服务器的供应商放弃前缀 - 您的应用程序特定的私有API，个人数据 - 传递机制变得更加绝对 - 与少量官方保留 Headers 名称的名称空间冲突隔离 . 也就是说，我的个人偏好和建议是更进一步，例如， “X-ACME-ClientDataFoo”（如果您的小部件公司是“ACME”） .

恕我直言，IETF规范没有足够具体来回答OP的问题，因为它无法区分完全不同的用例：（A）供应商一方面引入新的全球适用功能，如“Forwarded-For”，与（B） app开发人员将特定于应用程序的字符串传递给客户端和服务器 . 该规范仅涉及前者（A） . 这里的问题是（B）是否有惯例 . 有 . 它们涉及按字母顺序将参数分组，并将它们与（A）类型的许多标准相关 Headers 分开 . 使用“X-”或“X-ACME-”前缀对于（B）来说是方便和合法的，并且不与（A）冲突 . 越多的供应商停止使用“X-”作为（A），（B）将变得越清晰 .

Example:
谷歌（在各种标准组织中承担了一些权重） - 截至今日，20141102这个对我的回答的轻微编辑 - 目前使用"X-Mod-Pagespeed"来表示他们的Apache模块的版本涉及转换给定的响应 . 有人真的建议谷歌应该使用"Mod-Pagespeed"，没有"X-"，和/或要求IETF保佑它的使用吗？

Summary:
如果您在应用程序中使用自定义HTTP标头（作为有时候合适的Cookie替代品）来向服务器传送数据或从服务器传递数据，并且这些标头明确地不打算在应用程序的上下文之外使用，使用"X-"或"X-FOO-"前缀对它们进行名称间隔是一种合理且通用的约定 .

回复于 2024-04-28T06:05:08+08:00
4

修改或更正确地添加额外的HTTP头是一个很好的代码调试工具，如果没有别的 .

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

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

我经常添加额外的HTTP标头，如X-fubar-somevar：或X-testing-someresult：测试出来的东西 - 并且发现了许多本来很难追查的错误 .

回复于 2024-04-28T06:05:08+08:00
446

2012年6月，对于使用"X-"前缀的建议的弃用已成为正式RFC 6648 . 以下是相关的引用：

3.新参数创建者的建议......不应在参数名前加上“X-”或类似结构 .

4.协议设计者的建议......不应禁止注册具有“X-”前缀或类似结构的参数 . 绝不能规定具有“X-”前缀或类似结构的参数需要被理解为非标准化 . 绝不能规定没有“X-”前缀或类似结构的参数需要被理解为标准化 .

请注意"SHOULD NOT"（"discouraged"）与"MUST NOT"（"forbidden"）不同，有关这些关键字的其他规范，另请参阅RFC 2119 . 换句话说，您可以继续使用"X-"前缀 Headers ，但不建议这样做，您可能不会将它们记录为公共标准 .

2011年6月，第一个IETF draft被发布到 deprecate 使用"X-"前缀的建议对于非标准 Headers . 原因是，当前缀为"X-"的非标准头文件成为标准时，删除"X-"前缀会破坏向后兼容性，从而迫使应用程序协议支持这两个名称（例如，等等） . （例如， x-gzip 和 gzip ） . 所以，建议只是在没有"X-"前缀的情况下明智地命名它们 .

建议 was 以"X-"开头 . 例如 . X-Forwarded-For，X-Requested-With . 这也在a.o中提到 . RFC 2047的第5节 .

回复于 2024-04-28T06:05:08+08:00
984
HTTP标头的格式在HTTP规范中定义 . 我将讨论HTTP 1.1，其规范是RFC 2616 . 在4.2节，'Message Headers'中，定义了 Headers 的一般结构：
```
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>
```
该定义基于两个主要支柱：令牌和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 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].
```
那么，有两个结论 . 首先，很明显 Headers 名称必须由ASCII字符的子集组成 - 字母数字，一些标点符号，而不是其他许多字符串 . 其次， Headers 值的定义中没有任何内容将其限制为ASCII或排除8位字符：它明确地由八位字节组成，仅禁止控制字符（注意CR和LF被视为控件） . 此外，对TEXT产生的评论暗示八位字节将被解释为在ISO-8859-1中，并且存在用于表示该编码之外的字符的编码机制（这是偶然的，可怕的） .

因此，特别要回应@BalusC，很明显根据规范， Headers 值在ISO-8859-1中 . 我已经在Tomcat的 Headers 中发送了高8859-1个字符（特别是法语中使用的一些重音元音），并且让它们被Firefox正确解释，所以在某种程度上，这在实践和理论上都有效 . （虽然这是一个包含URL的Location标头，这些字符在URL中不合法，所以这实际上是非法的，但是在不同的规则下！） .

也就是说，我不会依赖ISO-8859-1在所有服务器，代理和客户端工作，所以我会坚持使用ASCII作为防御性编程的问题 .
回复于 2024-04-28T06:05:08+08:00
14

RFC6648建议您假设您的自定义标头"might become standardized, public, commonly deployed, or usable across multiple implementations."因此，建议不要在其前面添加"X-"或类似的结构 .

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

回复于 2024-04-28T06:05:08+08:00
14

Headers 字段名称注册表在RFC3864中定义，"X-"没有什么特别之处 .

据我所知，私有 Headers 没有指导原则;有疑问，避免它们 . 或者查看HTTP扩展框架（RFC 2774） .

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

回复于 2024-04-28T06:05:08+08:00

自定义HTTP标头：命名约定

6 回答

相关问题