Http自定义请求头包含下划线无法正常传递

在使用zuul进行url路由转发过程中，我们想添加自定义的请求头如“xl_access_token”。转发的请求是通过url的方式先转发给nginx，然后再由nginx转发给应用。

奇怪的现象发生了，处理请求的应用居然找不到自定义的请求头“xl_access_token”。后来我们发现没有使用“_”的请求头都能正常传递，所以我们修改自定义请求头为“authuserid”（也就是去掉下划线），最终应用成功获取到了自定义的请求头。

那么，服务器为何要对字段名中使用了下划线的请求头视若无物呢？

在 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，也在此范围之内！

其实，在 HEADER字段名中使用下划线其实是合法的、符合 HTTP 标准的。服务器之所以要默认禁止使用是因为 CGI 历史遗留问题。下划线和中划线都为会被映射为 CGI 系统变量名中的下划线，这样容易引起混淆。

在 nginx 服务器中，通过显式地设置

underscores_in_headers on

可以开启在字段名中使用下划线。默认该选项是关闭的，所以在默认情况下，所有包含下划线的字段名都会被丢弃。因此强烈建议不要在 HEADER 的 Field-Name 中使用下划线。

(HTTP不区分大小写)