通过业务场景理解跨域与请求(简单与非简单)

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/HCJS_Zee/article/details/88354041

业务场景中出现的问题

近期我单独负责一个项目的前端工作,在网络方面是和后端分离开发,在前端发起网络请求就会存在跨域的问题。

tips:由于开发阶段前后端分离,所以会存在种种的跨域情况,为了便于开发联调所以才进行跨域处理

通常的解决方案是CORS(跨域资源共享),CORS需要浏览器和服务器同时支持。由于本地浏览器基本都支持这个方案,所以仅需要后端进行相应的allow配置。当后端配置好以后,按道理应该没有请求跨域问题了,但是涉及到post请求会产生跨域问题。

问题的表现

在通过POST请求服务器的资源时,浏览器控制台出现跨域以及预请求问题。我们请求服务器资源的过程实际上是发送请求到服务器资源所映射的一个IP地址。Web代理服务通过Nginx来实现,它收到前端的请求以后,将请求传递给W框架,并拦截OPTIONS请求,回绝404。
Nginx接收到W框架的反馈,则表现为302临时重定向。由于访问不到服务器的资源,所以就会重定向到公司统一的404页。

问题的定位

我们整个项目后端的服务是强依赖公司的一个(类Spring MVC)W框架,它在处理网络请求的过程会进行过滤(有相应的过滤模块),由于W框架的设定,目前只支持HEAD、GET、POST三种请求方式,因此其余的请求方式会被拦截,我的POST请求被拦截了吗?答案是错误的,拦截的不是POST而是预检请求OPTIONS。什么是OPTIONS请求?什么时候会出现OPTIONS请求?

什么是OPTIONS请求

接近官方的定义如下:

HTTP 的 OPTIONS 方法 用于获取目的资源所支持的通信选项。客户端可以对特定的 URL 使用 OPTIONS 方法,也可以对整站(通过将 URL 设置为“*”)使用该方法。 --MDN WEB DOCS

OPTIONS请求也是在进行非简单请求才会出现的。(补充简单与非简单请求)
浏览器将CORS请求分成两类

两种请求

同时满足一下两大条件,就属于简单请求。

 (1)请求方法是一下三种之一
	HEAD
	GET
	POST
 (2)HTTP的头信息不超出一下几种字段
	Accept
	Accept-Language
	Content-Language
	Last-Event-ID
	Content-Type:只限于三个值(application/x-www-form-urlencoded、multipart/form-data、text/plain)

凡是不同时满足上面两个条件,就属于非简单请求。

什么时候会出现OPTIONS请求

非简单请求会在正式通信之前,增加一次HTTP查询请求,就是我们所说的OPTIONS预检请求。

所以OPTIONS预检请求的出现条件:请求为非简单请求

回归问题本身

请求失败的原因在于OPTIONS请求没有被W框架支持,由于项目强依赖W框架,所以有以下两种解决方案:
一、不跨域,这样就不会产生非简单请求,也就不会发送OPTIONS预检请求。
二、跨域但不发送非简单请求,简单请求也不会发送OPTIONS预检请求。

由于我们的业务需要(Content-Type: application/json),且前端采用的网络框架axios默认Content-Type为application/json,这样就导致跨域一定会发送非简单请求,所以只能采用方案一。

解决问题

CORS本来就是跨域问题的解决方案,但是却受到了(low)W框架的影响。
解决跨域还可以通过前端设置代理(proxy)的方式模拟本域进行通信。
以下是vue框架的proxy代理方案

proxyTable: {
	'/api': {
		 target: 'http://www.example.com', // 设置你调用的接口域名和端口号
       	 changeOrigin: true,     // 跨域
         pathRewrite: {
         '^/api': '/'          
        }
   }
}

总结

当我们再次解决了项目的跨域问题以后,使得网络通信变得顺畅。此次问题的解决投入了我较大的精力,问题出现的原因在于:1、经验的欠缺;2、问题定位不够准确;3、对原有概念的偏差理解。只能继续加油呀。

猜你喜欢

转载自blog.csdn.net/HCJS_Zee/article/details/88354041