跨域时产生了 OPTIONS 请求【以下是转载内容】码字很辛苦，转载请注明来自tuy博客的《XMLHttpRequest跨域时产生了OPTIONS请求》一：前言对于跨域请求，一直没有采用jsonp方式，原因如下1.jsonp只支持get请求而不支持post请求,如果想传给后台一个json格式的数据,浏览器会返回一个415的状态码，告诉我们请求格式不正确，这让传输大规模数据变得繁琐。2.无法准确定位和调试…
【以下是转载内容】
码字很辛苦，转载请注明来自tuy博客的《XMLHttpRequest 跨域时产生了 OPTIONS 请求》
一：前言
对于跨域请求，一直没有采用jsonp方式，原因如下
1.jsonp只支持get请求而不支持post请求,如果想传给后台一个json格式的数据,浏览器会返回一个415的状态码，告诉我们请求格式不正确，这让传输大规模数据变得繁琐。
2.无法准确定位和调试请求异常情况
3.存在安全性问题(可能是我的技术盲点，因为看到很多大公司都用jsonp技术)
考虑到以上问题，并且跨域资源共享标准 允许XMLHttpRequest 或 Fetch 发起跨域 HTTP 请求，前后端约定数据请求一律采用XMLHttpRequest，通过后台设置响应报文头 Header set Access-Control-Allow-Origin *，即可实现跨域访问。为了防止XSS攻击， 我们又进行域名限制，比如 Access-Control-Allow-Origin: http://www.xudihui.com
二：正文
用了好几个项目下来，一直没出问题。今天维护老项目时，发现请求新接口并不能准确拿到业务数据，而是触发了一个OPTIONS请求,请求头如下：
|
1
2
3
4
5
6
7
8
9
10
11
|
OPTIONS http://activity.96225.com/win_smk_activity/baseUser/getUserIdByToken.ext HTTP/1.1
Host: activity.96225.com
Connection: keep-alive
Access-Control-Request-Method: POST
Origin: http://192.168.2.176:4000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Access-Control-Request-Headers: appid
Accept: */*
Referer: http://192.168.2.176:4000/
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
|
从请求头来看，OPTIONS请求前端代码并没有发起，仔细查看请求头字段：
字段 Access-Control-Request-Method 告知服务器，实际请求将使用 POST 方法；
字段 Access-Control-Request-Headers 告知服务器，实际请求将携带一个自定义请求首部字段：appid，appid是用来告知服务端业务逻辑使用，ajax被封装之后，appid携带在该项目所有请求头中；
字段 Host 告诉我们服务器主机名；
字段 Referer 显示了本地开发地址，Host和Referer是典型的跨域请求。
带着疑问去了解OPTIONS请求，首先查看了ajax方法，除了xhr对象序列和增加了一个请求头appId之外，并没有其它逻辑，代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
|
var ajax_ = function(obj) {
obj = obj || {};
obj.type = (obj.type || 'GET').toUpperCase();
obj.dataType = obj.dataType || 'json';
obj.timeout = obj.timeout || 20000;
var params = formatParams(obj.data); //参数格式化
var xhrTimeout;//前端定时放弃
//step1:兼容性创建对象
if (window.XMLHttpRequest) {
var xhr = new XMLHttpRequest();
} else {
var xhr = new ActiveXObject('Microsoft.XMLHTTP');
}
if(AJAX_ == 0){
UI.showIndicator();
}
AJAX_++;
//step4: 接收
xhr.onreadystatechange = function() {
if (xhr.readyState == 4) {
AJAX_--;
if(AJAX_== 0){
UI.hideIndicator();
}
try{
if (xhr.status >= 200 && xhr.status < 300) {
obj.success && obj.success(xhr.responseText, xhr.responseXML);
} else {
obj.error && obj.error(xhr.status);
}
}catch(e){}
}
}
//step2 step3:连接 和 发送
if (obj.type == 'GET') {
xhr.open('GET', obj.url + '?' + params, true);
xhr.setRequestHeader('appId', $APPID);
xhr.send(null);
} else if (obj.type == 'POST') {
xhr.open('POST', obj.url, true);
//设置请求头，以表单形式提交数据
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.setRequestHeader('appId', $APPID);
xhr.send(params);
}
// 超时,默认20秒，直接设置timeout属性：https://www.w3.org/TR/2012/WD-XMLHttpRequest-20120117/#handler-xhr-ontimeout
xhr.timeout = obj.timeout;
xhr.ontimeout = function(){
UI.toast('请检查网络连接是否正常',2000,'exception');
}
//辅助函数，格式化参数
function formatParams(data) {
var arr = [];
for (var name in data) {
arr.push(encodeURIComponent(name) + "=" + encodeURIComponent(data[name]));
}
//设置随机数，防止缓存
arr.push("t=" + Math.random());
return arr.join("&");
}
}
|
通过stackoverflow的这篇文章，得知我遇到的OPTIONS是浏览器发起的’preflight’请求，征求服务器是否允许该实际请求。”预检请求“的使用，可以避免跨域请求对服务器的用户数据产生未预期的影响。但是我其它项目中并没有产生OPTIONS请求，它是从哪里来的呢，继续查看触发条件，当满足以下条件时，浏览器主动触发OPTIONS请求：
1、使用了下面任一 HTTP 方法：
– PUT
– DELETE
– CONNECT
– OPTIONS
– TRACE
– PATCH
2、人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为：
– Accept
– Accept-Language
– Content-Language
– Content-Type (but note the additional requirements below)
– DPR
– Downlink
– Save-Data
– Viewport-Width
– Width
3、 Content-Type 的值不属于下列之一:
– application/x-www-form-urlencoded
– multipart/form-data
– text/plain
条件1并没有匹配，前端采用标准的POST请求；条件三也没有匹配，请求头Content-Type也是标准值：xhr.setRequestHeader(‘Content-Type’, ‘application/x-www-form-urlencoded’);
主要原因就是条件2，我们定义了非安全的首部字段appId，设值的初衷，就是让服务端通过此它能更方便地来做业务逻辑。
在前端把xhr.setRequestHeader(‘appId’, $APPID)去掉之后，浏览器不进行OPTIONS服务器预检测，直接进入业务逻辑，正确发送POST请求，并且跨域成功。
到此处，其实仅仅解决我们的跨域问题已经完成了，只要把appId放到请求send数据中去，移除头部appId字段，就能成功进行前后端交互了。但appId这个字段当初放在头部，就是考虑到它有别于业务逻辑，跟业务代码一起放在请求体中不是特别合适，决定再看看有没有其它方法，允许设置自定义头并且成功跨域的方案。
感谢mozilla developer，提供了关于跨域非常详细的资料，大家可以看看。里面也提到了我当前场景的解决方案，马上着手开始实践，为了创造一个跨域环境，我先用nginx起一个127.0.0.1:8080的服务器，然后在这个地址中使用XMLHttpRequest 对象，发起目标为192.168.1.6地址的请求，192.168.1.6使用node js创建一个带有基础响应头的服务器，代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
|
const http = require('http');
const hostname = '192.168.1.6'; //使用ipconfig -all查看本机IP地址，然后使用127.0.0.1地址进行访问
const port = 3000;
//支持跨域的服务器搭建
const server = http.createServer((req, res) => {
res.statusCode = 200;
res.setHeader('Content-Type', 'application/json;charset=UTF-8');
res.end('{"code":-3,"msg":"APPID不能为空","response":null,"systemDate":"2017-07-13"}');
});
server.listen(port, hostname, () => {
console.log('Server running at http://'+hostname+':'+port);
});
|
使用fiddler查看报文如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
//请求报文如下：
OPTIONS http://192.168.1.6:3000/ HTTP/1.1
Host: 192.168.1.6:3000
Connection: keep-alive
Access-Control-Request-Method: GET
Origin: http://127.0.0.1:8080
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36
Access-Control-Request-Headers: appid
Accept: */*
Referer: http://127.0.0.1:8080/dev/SVN_/h5Main/trunk/alipay/virtualCard20170509/src/pages/test/3-new.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: zh-CN,zh;q=0.8
//响应如下：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Date: Fri, 14 Jul 2017 15:11:34 GMT
Connection: keep-alive
Content-Length: 79
{
"code":-3,"msg":"APPID不能为空","response":null,"systemDate":"2017-07-13"}
|
可以看到通过在前端增加appid请求头，访问node js 搭建的服务器,浏览器触发了OPTIONS 预检验请求，但是服务端的响应头中没有设置Access-Control-Allow-Origin也没有允许OPTIONS请求，它却成功跨域拿到了json数据。发生这种情况首先想到的就是服务器环境不一致，我们后台使用的是java的spring mvc 肯定比node js 复杂千万倍。于是把这个问题反馈给后台同学，他们通过审查配置文件后发现，OPTIONS在java 的 spring MVC 框架中默认是禁止放行的。资料显示，框架认为这是不安全的行为，确实，不仅跨域还添加自定义请求头。于是开始改造后台响应报文，我配合后台一起调试。最后在原有基础上增加如下配置：
‘Access-Control-Allow-Headers’, ‘appId’ 来允许服务器请求中携带字段appId，如果还有其它字段，可以用逗号分隔填入；
‘Access-Control-Allow-Methods’,’: POST, GET, OPTIONS’来允许服务器允许客户端使用 POST, GET 和 OPTIONS 方法发起请求;
添加完毕之后，响应头中增加对应字段，可以成功实现带自定义首部字段的跨域通信。
|
1
2
3
4
5
6
|
//响应头局部：
HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Access-Control-Allow-Headers: appId
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Origin: *
|
但是我们发现每次这种情况都会触发OPTIONS请求，然后再去执行业务逻辑，虽然正常执行了，但是一个请求变成了两个，肯定增加了用户等待时间和服务器资源消耗，于是又在响应头中增加了Access-Control-Max-Age: 86400；表明该响应的有效时间为 86400 秒，也就是 24 小时。在有效时间内，浏览器无须为同一请求再次发起预检请求。浏览器自身维护了一个最大有效时间，如果该首部字段的值超过了最大有效时间，将不会生效。最后同一天内一个接口就只有一次OPTIONS请求啦，大功告成！
三：参考资料 stackoverflow、w3 跨域文档、HTTP访问控制
今天的文章跨域时产生了 OPTIONS 请求分享到此就结束了，感谢您的阅读。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/7662.html
