请求头的真正较量之Nginx与下划线

最近开发了一个Spring Boot + Nginx + LayuiAdmin项目，在上线时遇到了如下血淋淋的战场，请君细看。

首先在测试环境时，请求都能够从LayuiAdmin的一个网页中发起admin.req到Spring Boot项目，而且只要登录之后，服务器会向前端响应access_token的值，只要需要登录的接口，都会带上这个access_token的请求头的值。

不料，被我发现了第一个战场亮点如下：

如果Spring Boot 中没有配置CORS【如果还不懂CORS,可以查看我之前的文章】，则前端向后端发送请求时，前端的IP，协议和端口和后端的IP，协议和端口只要有一个不一致，都不能够正常请求，会遇到CORS错误，故在Spring Boot 中增加如下配置类：

@Configuration
public class GlobalWebConfig extends WebMvcConfigurationSupport {
    /**
     * 解决CORS的问题
     *
     * @param registry cors注册对象
     */
    @Override
    protected void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedHeaders("*")
                .allowedMethods("*")
                .allowedOrigins("*")
                .allowCredentials(true)
                // 向前端js暴露的请求头
                .exposedHeaders("access_token");//此处是第二个战场较量处
    }
}

为了解决IP和端口的一致，则需要在Nginx中配置路径，也就是说前端和后端都在同一个Server中配置，只是后面的路径不一样，所以增加了如下Nginx的配置

	server {
		listen       443 ssl;
		server_name  clbgw.vip;
		underscores_in_headers on;# 此处是第三个战场较量处
		ssl_certificate       cert/clbgw.vip.pem;
		ssl_certificate_key   cert/clbgw.vip.key;
		
		ssl_session_cache    shared:SSL:10m;
		ssl_session_timeout  10m;
		ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM;
		ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
		ssl_prefer_server_ciphers  on;
		
		location /encry/ {
		    add_header Access-Control-Allow-Origin *;
			add_header Access-Control-Allow-Headers "*";
			add_header Access-Control-Allow-Methods "GET,POST,PUT,DEELETE,OPTIONS";
            proxy_pass http://xckyEncry/;
        }

		location /layui/ {
			add_header Access-Control-Allow-Origin *;
			add_header Access-Control-Allow-Headers "*";
			add_header Access-Control-Allow-Methods "GET,POST,PUT,DEELETE,OPTIONS";
		    alias   html/layui/;
		}
	}

这样前端路径：https://clbgw.vip/layui 和后端路径 https://clbgw.vip/encry 就同协议，同IP和同端口,也就解决了CORS的根本性问题了。

解决完第一个问题就结束了吗，不，还有第二个容易忽视的亮点。

再说下关于后端返回的access_token响应头为什么在前端的js中无法获取？那是因为Spring Boot没有暴露响应头或者请求头，故在CORS的基础上增加如下代码：

.exposedHeaders("access_token");

那么这第二个问题也就轻松解决了。

那么再赠送第三个战场发现的亮点，那就是更加细小的问题：【access_token】这个请求头有没有觉得很可疑。

这第三个亮点就是这个access_token的下划线，这也是我这次解析和分析许久的问题，但是最终的解决办法就是在nginx中的http节点出增加如下配置：

underscores_in_headers on;

默认nginx是会忽略请求头中包含的下划线请求头的key，那么解决办法就至少有两个，一个是请求头的key不使用下划线，比如access-token 或者accessToken 或者token都是可以的，就能够避免这个问题了，当然另外一个简单的办法就是在nginx增加如上开启下划线的请求头配置了。

现在你get到如上三个亮点了吗？如果你也跟我一样喜欢解决问题，可以一键三连，关注我就可以更及时看到我的精彩分享啦！