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

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

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

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

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

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

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

“HTTP”有两个级别：一个更抽象的上层，包含 HTTPsemantic (e.g. PUT资源r1），以及对该语义进行编码的较低层。将这两者分别视为 HTTP 的应用层和 HTTP 的网络层。

应用层可以完全不知道HTTP请求是否语义化PUT r1已以 HTTP/1.1 或 HTTP/2 格式发布。
另一方面，同样的语义，PUT r1，网络层在 HTTP/1.1（文本）和 HTTP/2（二进制）中的编码方式不同。

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

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

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