HTTP Header 指南

已弃用的 X-Foo 命名方案

在 RFC 6648 中，建议使用X-作为应用特定 header 的前缀已被撤回。它在 RFC 2616 中被定义为实现者永久保留的前缀，但由于迁移带有前缀的 header 到标准化 header 的复杂性，已被弃用。这导致一些标准同时保留带有 X- 前缀和不带前缀的 header 名称。（参见 X-Archived-At/Archived-At）在更新的 RFC 7231 中，新协议的设计者被 discouraged 不要使用带有 X- 前缀的 header，并在可能的情况下保持新的 header 简短。

指导

这并不意味着建议替换现有使用的X-，或者在私有/本地/开发环境中继续使用X-。新的 API（或新的 API 功能）应该尽最大努力避免使用与其他应用程序冲突的 header 名称。为此，在 header 中使用“OpenStack”和服务的名称。例如“OpenStack-Compute-FooBar”，这不太可能已经被标准化或与现有 header 冲突。

RFC 6648 故意没有禁止使用X-作为前缀，但它确实移除了该前缀的实验性/非标准化语义。对于现有项目，创建带有 X- 前缀的新 header 是可以接受的，因为 API 中已经标准化的其余 header 很可能以X-.

示例

一些好的 header 名称清晰、不太可能冲突，并且可能被标准化，例如OpenStack-Identity-Status一些存在冲突风险的 header 可能如下所示

Account-ID
Host-Name
Storage-Policy

在这些情况下，添加OpenStack-作为前缀可以消除歧义，例如

OpenStack-Identity-Account-ID
OpenStack-Networking-Host-Name
OpenStack-Object-Storage-Policy

避免 Header 泛滥

使用 header 名称作为在客户端和服务器之间传递特定信息的方式可能很诱人。在可能的情况下，应该避免这样做，而倾向于使用更通用的 header 名称，并将具体内容放在值中。例如，比较以下两个 header

OpenStack-API-Version: compute 2.1
OpenStack-Nova-API-Version: 2.1

注意

第一个 header 是推荐的形式。第二个 header 是当前正在使用的 microversion header 的形式。它有效地演示了这个问题。另外请注意，虽然第二个 header 使用服务名称，但第一个 header 使用更正确的服务类型。

乍一看，这些 header 名称和值对传达相同的信息，第二个选项在服务器端更容易解析。但是，请考虑在使用第二种形式时可能出现以下问题

• 每当有新的服务时，就需要一个新的 header。
• 它违反了基于键值数据结构的原则，即键应该只是一个访问器，也就是说：它应该是不透明和通用的。
• 如果正在使用 CORS [1] 中间件，则需要配置它以允许大量的 header，而不是一个通用的 header。
• 在客户端或服务器中，应该处理此类 header 的通用库代码必须在名称-值对的两侧构造或解析字符串。

[1]	https://mdn.org.cn/en-US/docs/Web/HTTP/Access_control_CORS