nginx线上环境获取不到header头token登录信息
背景
一次项目上线后,输入正确信息登录后,却提示"登录失效,请重新登录",测试环境和预生产环境都没问题,排除应该不是代码问题。查看日志定位到代码,应该是线上没有获取到header头中的access_token(之前的名字是login-token,本次改成了access_token)导致的。然后为了验证,在服务器上通过curl 直接访问 后端的服务ip:port 的方式返回了正确的信息,大概定位到是 nginx代理转发到应用服务器时,header头信息丢失问题。
解决
初步定位问题后,就百度搜索了下 “nginx header 丢失”
发现 header的头的 变量 name 中包含 “_” 下划线导致的。
为什么测试环境、预生产环境可以呢? 经过对比nginx配置文件发现,测试和预生产环境配了
underscores_in_headers on;
header中自定义变量名时不要用下划线
个人比较推荐这种方式。常见的header变量都是遵循这种方式,例如:Content-Type,Content-Length,Accept-Ranges等。
但是本次是上线过程中发现的问题,就采用了方案二
在nginx里的nginx.conf配置文件中的http部分中添加如下配置:
nginx默认request的header的那么中包含_时,会自动忽略掉。
解决方法是:在nginx里的nginx.conf配置文件中的http部分中添加如下配置:
underscores_in_headers on;
其他
在 RFC 2616 4.2 节中,有如下一段话:
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message).
这段话的意思,就是说HTTP/1.1的请求和响应消息使用 RFC 822 中的通用消息格式来传输实体(消息载荷)。
在 RFC 822 3.1.2节中,对于消息格式的说明,有这样一句话:
The field-name must be composed of printable ASCII characters (i.e., characters that have values between 33. and 126., decimal, except colon).
也就是说,HEADER 字段名可以可由可打印的 ASCII 字符组成(也就是十进制值在 33 和 126 之间的字符,不含冒号)。不含冒号很容易理解,因为 Field-Name和Value之间需要用冒号分割。然而,我们通过查询 ASCII 码表可知,下划线的十进制 ASCII 值为 95,也在此范围之内!
如果未显式设置underscores_in_headers on;
nginx会静默删除带下划线的HTTP标头(根据HTTP标准完全有效)。这样做是为了避免将标头映射到CGI变量时出现歧义,因为在此过程中,短划线和下划线都映射到了下划线。
服务器之所以要默认禁止使用是因为 CGI 历史遗留问题。下划线和中划线都为会被映射为 CGI 系统变量名中的下划线,这样容易引起混淆。