前提：uniapp chorem浏览器调试
例如：header:{'test':'234'}
java后台请求函数中打印res.getHeader("test")没值,并且chorem调试发现request headers中也没有。
6***@qq.com
- 发布：2018-11-30 15:54
- 更新：2019-10-30 21:29
- 阅读：18299
uni.request设置header，自定义属性后端找不到。
分类：uni-app
前提：uniapp chorem浏览器调试
例如：header:{'test':'234'}
最佳回复
李继刚 - huaweu . options manager
同问题，其他项目调用好用，就uni目前不好用。坐等。但是只是浏览器h5执行取不到token 小程序好用的。
-
6***@qq.com (作者)
header:{'phone':uni.getStorageSync('phone')}
看看是不是header写错了，我是因为写错了2019-05-16 16:11
我后端也没法拿到头信息，你解决了吗
-
6***@qq.com (作者)
header:{'phone':uni.getStorageSync('phone')}
我就这样写的，当时应该是header写错了吧，好像写成headers了
2019-05-16 16:10
请求类型设置的是post 但是前端添加header后，变成了options请求，后端拿不到token值
SpringBoot项目解决方案（ 注意看有没有.allowedHeaders("*") ）：
registry.addMapping("/**").allowedOrigins("*").allowedMethods("*").allowedHeaders("*");
WebMvcConfigurer.super.addCorsMappings(registry);-
加了上面.allowedHeaders("*") 发现还是不管用，后来百度到下面的这段话：
在 CORS 中，可以使用 OPTIONS 方法发起一个预检请求，以检测实际请求是否可以被服务器所接受。预检请求报文中的 Access-Control-Request-Method 首部字段告知服务器实际请求所使用的 HTTP 方法；Access-Control-Request-Headers 首部字段告知服务器实际请求所携带的自定义首部字段。服务器基于从预检请求获得的信息来判断，是否接受接下来的实际请求。
服务器所返回的 Access-Control-Allow-Methods 首部字段将所有允许的请求方法告知客户端。该首部字段与 Allow 类似，但只能用于涉及到 CORS 的场景中。
意思已经很明白了，就是说跨域的时候，会先有一个OPTIONS的请求，把我们当前请求的方法Access-Control-Request-Method：GET/POST带上，把我们要携带的header Access-Control-Request-Headers：token带上，发给服务器，服务器会做出响应告诉请求端 我服务器允许你哪种请求方法Access-Control-Allow-Methods: POST, GET, OPTIONS
允许你带什么header值 Access-Control-Allow-Headers: token，请求端收到响应之后，判断满足服务器的这些要求，才会发送真正的请求，才会携带header token: 055828BFB434D92DE79DF52027B358A6 ，服务端才能获取到token；
说了半天怎么做是关键：
服务端判断request.getMethod是OPTIONS请求的时候，设置response如下，然后直接return响应给请求端：
response.setHeader("Access-Control-Allow-Origin", "*");
response.setHeader("Access-Control-Allow-Methods", "POST, PUT, GET, OPTIONS, DELETE, PATCH");
response.setHeader("Access-Control-Allow-Headers", "origin, content-type, accept, x-requested-with, token");
response.setHeader("Access-Control-Max-Age", "3600");
请求端做出判断之后，发送真正的GET/POST请求，上面的代码因只有OPTIONS请求才会执行，所以直接跳过，执行后面真正的逻辑
2019-10-24 12:59
-
注意OPTIONS预检请求，服务器响应之后，请求端是会对响应结果进行缓存的，也就是说预检请求只有一次，后面发送的都是真正的请求。
所以如果你加上上面的几行代码，然后通过浏览器发送一个请求，发现正常了，然后又去掉这几行代码，在浏览器没有关闭的情况下，再次发送请求，会发现仍然是正常的，疑惑了？不用疑惑，关掉浏览器重新打开，你就发现没这几行代码不行
缓存的原因，我想可能是这行代码的作用吧，也可能不是，我没有测试
response.setHeader("Access-Control-Max-Age", "3600");2019-10-24 13:16
以下文章链接解决uni-app开发环境中H5端跨域问题
解决uni-app开发环境中H5端跨域问题
此跨域问题只存在于浏览器端，App和小程序不存在跨域问题
参考地址：
manifest.json官方配置文档： https://uniapp.dcloud.io/collocation/manifest?id=devserver
Chrome 调试跨域问题解决方案之插件篇： https://ask.dcloud.net.cn/article/35267
其实uni-app官方有解决跨域的办法，官方推荐使用HBuilderX中内置的浏览器去预览，在内置的浏览器中不会存在跨域问题，但是要是在Chrome 浏览器中预览的话就会出现这个跨域问题，官方推荐使用Allow-Control-Allow-Origin: *插件的方式去解决，但是我试过这个插件，不知道是什么问题，并没有效果，跨域问题依旧还是存在，后面再仔细的看了下文档，看到了下面的提示。
uni-app 中 manifest.json->h5->devServer 实际上对应 webpack 的 devServer，鉴于 manifest 为 json 文件，故 webpack.config.js->devServer 配置项下的简单类型属性均可在manifest.json->h5->devServer节点下配置，funciton 等复杂类型暂不支持。
所以我就在想是不是可以使用proxy配置反向代理的方式去实现跨域请求，代码如下：
复制代码
/ h5特有相关 /
"h5" : {
"devServer" : {
"port" : 8000, //端口号
"disableHostCheck" : true,
"proxy" : {
"/api" : {
"target" : "https://xxx.xxxxx.cn", //目标接口域名
"changeOrigin" : true, //是否跨域
"secure" : false // 设置支持https协议的代理
}
}
}
}
复制代码
最后发现问题解决了。
ybs5431
同样遇到这样的问题 后端的请求类型设置的是post 但是前端添加header后，变成了options请求，后端拿不到token值，前端代码header: {
'content-type': 'application/x-www-form-urlencoded',
'Authorization': 'Bearer ' + _this.user.token
}
2019-06-18 11:56
DCloud_UNI_GSQ
回复 ybs5431: 后端需要先正确响应options，然后浏览器才会发起post请求，请你和后端一起百度一下options并学习。
2019-06-18 15:43
勇敢的心_
回复 DCloud_UNI_GSQ: 学习了学习了！！！
2021-01-11 16:17