nginx线上环境获取不到header头token登录信息

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 系统变量名中的下划线，这样容易引起混淆。