我正在构建一个API，我需要在消息通过系统时对其进行跟踪。为此，我计划使用X-Correlation-Id HTTP报头，但在这里我有一个问题。
首先，不赞成使用X-前缀，也不鼓励使用它。这样就只剩下Correlation-Id了。
第二，我打算使用连字符，但当我阅读https://www.rfc-editor.org/rfc/rfc7230时，我意识到连字符没有在任何地方明确命名。第3.2.6节提到排除的字符-这些字符是不可用的http头分隔符?
第三，因为HTTP头是不区分大小写的，我应该用小写来定义所有我期望的头吗?我问这个问题是因为我做的研究越多，我发现的变化就越多。有些api头文件大写，有些没有。有的用连字符，有的用下划线。
对于这些东西有明确的指导方针吗?我告诉我的老板，使用camelcase的HTTP头是不理想的，但我找不到任何指导方针。
-
只要使用是私有的，字段名就不是很重要。如有疑问，请使用"应用程序名称"。而不是"X"
-
字段名使用"标记"ABNF，其中包含"-"
-
因为它们是不区分大小写的，所以您如何定义它们并不重要。他们。如有疑问，请使用与HTTP规范相同的约定。CamelCase尤其没有帮助，因为HTTP/2(和3)上的所有内容都是小写的。
RFC 2822定义了header
的生成规则字段名必须由可打印的US-ASCII字符(即，值在33到126之间的字符，包括在内)组成，除了冒号。
您将在描述可选字段
的部分中找到ABNF表示。optional-field = field-name ":" unstructured CRLF
field-name = 1*ftext
ftext = %d33-57 / ; Any character except
%d59-126 ; controls, SP, and
; ":".
特别是在HTTP中，您需要注意附录B中定义的生成规则(注意，连字符- minus是允许的)
field-name = token
header-field = field-name ":" OWS field-value OWS
tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
"^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
token = 1*tchar
如果你查看IANA消息头注册表，你会发现相当多的消息头在拼写中包含连字符。仔细检查会发现许多标准的HTTP标头包含连字符(Accept-Language, Content-Type等)。
第三，因为HTTP头是不区分大小写的，我应该用小写来定义所有我期望的头吗?
对于您的规范，我建议与IANA注册表中的条目一致的拼写约定;在您的实现中，您将使用指定拼写的不区分大小写的匹配。