RFC 中关于 HTTP/2 区分大小写的问题似乎存在矛盾

Question

HTTP/2 的 RFC 中有一些令人困惑的术语，我希望能更清楚一些。

根据 RFC https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2

正如在 HTTP/1.x 中一样，标头字段名称是 ASCII 字符的字符串，以不区分大小写的方式进行比较。但是，标头字段名称在 HTTP/2 中编码之前必须转换为小写。包含大写标头字段名称的请求或响应必须被视为格式错误

这似乎概述了两个相互冲突的想法

• HTTP/2 中的标头字段名称不区分大小写
• 如果您接收或发送的字段不是小写，则请求/响应格式错误。

如果包含非小写标头的请求或响应无效，如何将其视为不区分大小写？

Answer 1

“HTTP”有两个级别：具有 HTTP语义（例如PUT资源）的更抽象的上层r1，以及对该语义进行编码的下层。将这两者分别视为 HTTP 的应用层和 HTTP 的网络层。

应用层可以完全不知道语义HTTP请求是以PUT r1HTTP/1.1还是HTTP/2格式到达的。
另一方面，PUT r1网络层在 HTTP/1.1（文本）和 HTTP/2（二进制）中对相同的语义 进行不同的编码。

规范的引用部分应在第一句中解释为引用应用程序层：“如 HTTP/1.1 中的标头名称应不区分大小写进行比较”。
这意味着，如果应用程序被询问“标头是否ACCEPT存在？”，则应用程序应以不区分大小写的方式查看标头名称（或确保实现提供此类功能），true如果存在Accept或则返回。accept

第二句话应该解释为指网络层：兼容的 HTTP/2 实现必须通过网络小写发送标头，因为这是 HTTP/2对要通过线路发送的标头名称进行编码的方式。

没有什么会禁止兼容的 HTTP/2 实现接收content-length: 128（小写），但随后将其转换为Content-Length: 128可供应用程序使用的标头 - 例如，为了最大程度地兼容 HTTP/1.1，其中标头的首字母为大写（例如打印在屏幕上）。