在HTTP/2的RFC中有一个术语有点令人困惑，我希望它能更清晰明了。
根据RFC https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2
与HTTP/1.x一样，头字段名称是由ASCII字符组成的字符串，大小写不敏感。但是，在HTTP/2中，头字段名称在编码之前必须转换为小写。包含大写头字段名称的请求或响应必须被视为格式错误
这似乎概述了两个相互冲突的想法
如果包含非小写标头的请求或响应无效，那么如何认为它是大小写不敏感的呢？
HTTP有两个层级：一个更抽象的上层，具有HTTP语义（例如PUT资源r1），以及一个低层，语义被编码的层。将它们分别看作HTTP的应用层和网络层。
应用层可以完全不知道语义HTTP请求PUT r1是以HTTP/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最大兼容性（例如在屏幕上打印）。
这是一个错误，或者至少是一个不必要混淆的规范。
头部名称必须进行大小写不敏感比较，但由于它们仅以小写形式传输或接收，因此这并不重要。
即在RFC中，“Content-Length”指的是头部“content-length”。
构建 HTTP/2 消息时，字段名必须转换为小写。
此外，现在的文本使用小写的头部名称。
