HTTP/2约束Header大小写

起因

晚上 Android 客户端遇到奇怪的问题：在某台新配的服务器上，出现应用层获取 Header 自定义键 Authorization 时出现其值为空，但存在键 authorization 。

调查

通过抓包发现几个疑点：

• 问题以前没有出现，业务也是正常的，唯独连接到这台服务器后出现异常

• 同一套代码，仅对这台服务器发出的请求没HTTP版本号，如：HTTP/1.1；
• 所有请求体、响应体的头字符全是小写；
• HTTP/1.1头大小写不敏感，且另外几台服务器Header约定俗成使用大写开头；
• iOS业务运行没有问题，但没有抓包查看；

先修复客户端 HTTP/1.1 大小写不敏感 实现为 大小写敏感 的严重问题。

调查的脚步不能就此终止，还要明确就为啥这台服务器如此突出。由于晚上问题发现时后端同事下班了，又一直按照HTTP/1.1的定义查找问题，丝毫没有进展。最后想到HTTP/2才如梦初醒，翻查RFC的官方文档。

RFC定义

文档 RFC7504 明确指出Header的定义：

8.1.2.  HTTP Header Fields

   HTTP header fields carry information as a series of key-value pairs.
   For a listing of registered HTTP headers, see the "Message Header
   Field" registry maintained at <https://www.iana.org/assignments/
   message-headers>.

   Just as in HTTP/1.x, header field names are strings of ASCII
   characters that are compared in a case-insensitive fashion.  However,
   header field names MUST be converted to lowercase prior to their
   encoding in HTTP/2.  A request or response containing uppercase
   header field names MUST be treated as malformed (Section 8.1.2.6).

从上文可知， HTTP/2 和 HTTP/1.x 同样使用 ASCII 字符集，但 HTTP/2 的头必须使用小写，而不是 HTTP/1.x 大小写均可。也正是碰上终端业务代码实现不严谨，才引发问题。

最终确认这台服务端 Nginx 开启了 HTTP/2 ，且客户端问题已修复提交，调查结束。

总结

对于任意网络协议，因为客户端在上层跟踪数据包有一定难度，所以先用抓包 工具 辅助是一个很好的习惯。

尽管各种协议更新演进，如果前端(业务代码、依赖库版本)或后端任意一方出现协议不兼容或实现不严谨，排查问题难度较高，所以实现上应尽可能做到细致严谨。

对客户端来说，把所有HTTP的Header键字符串转换为小写，业务匹配时也用小写键名称(即equalsIgnoreCase)同时适配 HTTP/2 和 HTTP/1.x 。注意，如果转小写后出现多个相同Header，必须要求服务端修正，同时前端调整代码。

• 上一篇

  EventBus源码剖析(5) -- Poster