HTTP/2约束Header大小写

December 13, 2018

起因

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

调查

通过抓包发现几个疑点:

  • 问题以前没有出现,业务也是正常的,唯独连接到这台服务器会出现异常;
  • 同一套代码,仅对这台服务器发出的请求行没有HTTP版本号,如:HTTP/1.1;
  • 所有请求首部、响应首部的字符全是小写;
  • iOS业务运行没有问题,所以没有抓包查看;

先修复客户端 HTTP/1.1 大小写不敏感 实现为 大小写敏感 的严重问题。调查的脚步不能就此终止,还要明确就为啥这台服务器如此突出。

由于晚上问题出现时后端同事下班了,又一直按照HTTP/1.1的定义查找问题,丝毫没有进展。最后想到HTTP/2才逐渐有头绪,后翻查RFC文档。

RFC定义

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

1
2
3
4
5
6
7
8
9
10
11
12
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/2HTTP/1.x 同样使用 ASCII 字符集,但 HTTP/2 头部必须使用小写,而不像 HTTP/1.x 大小写均可。也正是碰上终端业务代码实现不严谨,引发上述问题。

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

总结

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

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

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