- 服务端开发/管理
- HTTP/2约束Header大小写
#### 起因
晚上 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 .
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，必须要求服务端修正，同时前端调整代码。
