HTTP/2约束Header大小写

你的名字 2021-06-22 15:37 571阅读 0赞

起因

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

调查

通过抓包发现几个疑点：

*  问题以前没有出现，业务也是正常的，唯独连接到这台服务器会出现异常；
 *  同一套代码，仅对这台服务器发出的请求行没有HTTP版本号，如：HTTP/1.1；
 *  所有请求体、响应体的字符全是小写；
 *  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).

最终确认这台服务端 **Nginx** 开启了 **HTTP/2**，且客户端问题已修复提交，调查结束。从上文可知，**HTTP/2** 和 **HTTP/1.x** 同样使用 **ASCII** 字符集，但 **HTTP/2** 头部必须使用小写，而不像 **HTTP/1.x** 大小写均可。也正是碰上终端业务代码实现不严谨，引发上述问题。

总结

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

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

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

[RFC7504]: https://tools.ietf.org/html/rfc7540#section-8.1.2