前后端分离模大势所趋,跨域问题更是老生常谈。
问题背景:
浏览器最基本的安全规范-同源策略。所谓同源是指域名、协议、端口相同。不同源的浏览器脚本(javascript、ActionScript、canvas)在没有明确授权的情况下,不能读写对方的资源。
CORS就是w3c和浏览器厂商为解决跨域资源共享问题而推出的标准方案:它允许浏览器向跨源服务器发出脚本请求,CORS需要浏览器和服务器同时支持,它的通信过程都是浏览器自动完成的,不需要用户参与。
浏览机器一旦发现跨域,就会自动添加一些附加的头信息,有时还会多出一次附加的请求,但用户不会察觉,服务器响应特定标头Access-Control-,体现跨源访问的授权。
今天我主要想要聊一聊CORS中的预检请求
当前端使用脚本请求一个跨域资源时,如果是非简单请求(下文会解释),浏览器会自动帮你先发出一个OPTIONS
查询请求,称为预检(cors-preflight-request
),作用是询问服务器,当前网页所在的域名是否在服务器的许可名单之中,以及可以使用那些HTTP动词和头信息字段。 只有得到肯定答复,浏览器才会发生正式的XHR请求。
该请求header中会包含以下两个字段:
对于 OPTIONS 请求,按照规范实现的服务端会响应一组HTTP header,但不会返回任何实体内容。如果服务端支持该跨域请求,建议返回 204状态码(返回200也可以);如果不支持,建议返回403状态码(返回404或其他错误状态码也可以)。
响应的header可以包含以下字段:
由此可见,当触发预检时,一次AJAX请求会消耗掉两个TTL,严重影响性能。
那么如何节省掉 OPTIONS 请求来提升性能呢?从上文可以看出,有两个方案:
只要同时满足一下两个条件,就属于简单请求
(1)使用下列方法之一:
(2)请求的Heder是
不同时满足上面的两个条件,就属于非简单请求。
很明显,我们常见的Post请求、媒体类型Content-Type=application/json也属于非简单请求,也会触发预检请求。如果不方便改造为简单请求,只有使用方案2了。
Access-Control-Max-Age
字段当第一次请求该URL时会发出OPTIONS
请求,浏览器会根据返回的Access-Control-Max-Age
字段缓存该请求的OPTIONS预检请求
的响应结果。在缓存有效期内,该资源的请求(URL和header字段都相同的情况下)不会再触发预检。(chrome 打开控制台可以看到,当服务器响应Access-Control-Max-Age
时只有第一次请求会有预检,后面不会了。注意要开启缓存,去掉disable cache
勾选)
但是要注意的是,该缓存只针对这一个请求 URL 和相同的 header,无法针对整个域或者模糊匹配URL做缓存。(当然也可以考虑封装一下,固定一个接口地址,传不同的body内容)。
下面是Abp vNext配置CROS的示例:
private void ConfigureCors(ServiceConfigurationContext context, IConfiguration configuration)
{
context.Services.AddCors(options =>
{
// 无阻塞跨域
options.AddPolicy(DefaultCorsPolicyName, builder =>
{
builder.SetIsOriginAllowed(_ => true)
.AllowCredentials()
.AllowAnyHeader()
.WithMethods(HttpMethods.Get, HttpMethods.Post, HttpMethods.Put, HttpMethods.Delete)
.SetPreflightMaxAge(TimeSpan.FromHours(24));
});
});
}
评论已关闭。