从前后端的角度分析options预检请求

前后,端的,角度,分析,options,请求 · 浏览次数 : 149

小编点评

华为云新鲜技术,配置允许跨域请求,生成内容时需要带简单的排版。 华为云新鲜技术,配置允许跨域请求,生成内容时需要带简单的排版。 华为云新鲜技术,配置允许跨域请求,生成内容时需要带简单的排版。 华为云新鲜技术,配置允许跨域请求,生成内容时需要带简单的排版。 华为云新鲜技术,配置允许跨域请求,生成内容时需要带简单的排版。

正文

摘要:options预检请求是干嘛的?options请求一定会在post请求之前发送吗?前端或者后端开发需要手动干预这个预检请求吗?不用文档定义堆砌名词,从前后端角度单独分析,大白话带你了解!

本文分享自华为云社区《从前后端的角度分析options预检请求——打破前后端联调的理解障碍》,作者: 砖业洋__ 。

options预检请求是干嘛的?options请求一定会在post请求之前发送吗?前端或者后端开发需要手动干预这个预检请求吗?不用文档定义堆砌名词,从前后端角度单独分析,大白话带你了解!

从前端的角度看options——post请求之前一定会有options请求?信口雌黄!

你是否经常看到这种跨域请求错误?

这是因为服务器不允许跨域请求,这里会深入讲一讲OPTIONS请求。

只有在满足一定条件的跨域请求中,浏览器才会发送OPTIONS请求(预检请求)。这些请求被称为“非简单请求”。反之,如果一个跨域请求被认为是“简单请求”,那么浏览器将不会发送OPTIONS请求。

简单请求需要满足以下条件:

  1. 只使用以下HTTP方法之一:GET、HEAD或POST。
  2. 只使用以下HTTP头部:Accept、Accept-Language、Content-Language、Content-Type。
  3. Content-Type的值仅限于:application/x-www-form-urlencoded、multipart/form-data或text/plain。

如果一个跨域请求不满足以上所有条件,那么它被认为是非简单请求。对于非简单请求,浏览器会在实际请求(例如PUT、DELETE、PATCH或具有自定义头部和其他Content-Type的POST请求)之前发送OPTIONS请求(预检请求)。

举个例子吧,口嗨半天是看不懂的,让我们看看 POST请求在什么情况下不发送OPTIONS请求

提示:当一个跨域POST请求满足简单请求条件时,浏览器不会发送OPTIONS请求(预检请求)。以下是一个满足简单请求条件的POST请求示例:

// 使用Fetch API发送跨域POST请求
fetch("https://example.com/api/data", {
  method: "POST",
  headers: {
 "Content-Type": "application/x-www-form-urlencoded"
 },
  body: "key1=value1&key2=value2"
})
 .then(response => response.json())
 .then(data => console.log(data))
 .catch(error => console.error("Error:", error));

在这个示例中,我们使用Fetch API发送了一个跨域POST请求。请求满足以下简单请求条件:

  1. 使用POST方法。
  2. 使用的HTTP头部仅包括Content-Type。
  3. Content-Type的值为"application/x-www-form-urlencoded",属于允许的三种类型之一(application/x-www-form-urlencoded、multipart/form-data或text/plain)。

因为这个请求满足了简单请求条件,所以浏览器不会发送OPTIONS请求(预检请求)。

我们再看看什么情况下POST请求之前会发送OPTIONS请求,同样用代码说明,进行对比

提示:在跨域请求中,如果POST请求不满足简单请求条件,浏览器会在实际POST请求之前发送OPTIONS请求(预检请求)。

// 使用Fetch API发送跨域POST请求
fetch("https://example.com/api/data", {
  method: "POST",
  headers: {
 "Content-Type": "application/json",
 "X-Custom-Header": "custom-value"
 },
  body: JSON.stringify({
    key1: "value1",
    key2: "value2"
 })
})
 .then(response => response.json())
 .then(data => console.log(data))
 .catch(error => console.error("Error:", error));

在这个示例中,我们使用Fetch API发送了一个跨域POST请求。请求不满足简单请求条件,因为:

  1. 使用了非允许范围内的Content-Type值("application/json" 不属于 application/x-www-form-urlencoded、multipart/form-data或text/plain)。
  2. 使用了一个自定义HTTP头部 “X-Custom-Header”,这不在允许的头部列表中。

因为这个请求不满足简单请求条件,所以在实际POST请求之前,浏览器会发送OPTIONS请求(预检请求)。

你可以按F12直接在Console输入查看Network,尽管这个网址不存在,但是不影响观察OPTIONS请求,对比一下我这两个例子。

总结:当进行非简单跨域POST请求时,浏览器会在实际POST请求之前发送OPTIONS预检请求,询问服务器是否允许跨域POST请求。如果服务器不允许跨域请求,浏览器控制台会显示跨域错误提示。如果服务器允许跨域请求,那么浏览器会继续发送实际的POST请求。而对于满足简单请求条件的跨域POST请求,浏览器不会发送OPTIONS预检请求。

后端可以通过设置Access-Control-Max-Age来控制OPTIONS请求的发送频率。OPTIONS请求没有响应数据(response data),这是因为OPTIONS请求的目的是为了获取服务器对于跨域请求的配置信息(如允许的请求方法、允许的请求头部等),而不是为了获取实际的业务数据,OPTIONS请求不会命中后端某个接口。因此,当服务器返回OPTIONS响应时,响应中主要包含跨域配置信息,而不会包含实际的业务数据

本地调试一下,前端发送POST请求,后端在POST方法里面打断点调试时,也不会阻碍OPTIONS请求的返回

从后端的角度看options——post请求之前一定会有options请求?胡说八道!

在配置跨域时,服务器需要处理OPTIONS请求,以便在响应头中返回跨域配置信息。这个过程通常是由服务器的跨域中间件(Node.js—Express框架的cors中间件、Python—Flask框架的flask_cors扩展)或过滤器(Java—SpringBoot框架的跨域过滤器)自动完成的,而无需开发人员手动处理。

以下是使用Spring Boot的一个跨域过滤器,供参考

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;
@Configuration
public class CorsConfig {
 public CorsConfig() {
 }
 @Bean
 public CorsFilter corsFilter() {
 // 1. 添加cors配置信息
 CorsConfiguration config = new CorsConfiguration();
 // Response Headers里面的Access-Control-Allow-Origin: http://localhost:8080
 config.addAllowedOrigin("http://localhost:8080");
 // 其实不建议使用*,允许所有跨域
 config.addAllowedOrigin("*");
 // 设置是否发送cookie信息,在前端也可以设置axios.defaults.withCredentials = true;表示发送Cookie,
 // 跨域请求要想带上cookie,必须要请求属性withCredentials=true,这是浏览器的同源策略导致的问题:不允许JS访问跨域的Cookie
 /**
         * withCredentials前后端都要设置,后端是setAllowCredentials来设置
         * 如果后端设置为false而前端设置为true,前端带cookie就会报错
         * 如果后端为true,前端为false,那么后端拿不到前端的cookie,cookie数组为null
         * 前后端都设置withCredentials为true,表示允许前端传递cookie到后端。
         * 前后端都为false,前端不会传递cookie到服务端,后端也不接受cookie
         */
 // Response Headers里面的Access-Control-Allow-Credentials: true
 config.setAllowCredentials(true);
 // 设置允许请求的方式,比如get、post、put、delete,*表示全部
 // Response Headers里面的Access-Control-Allow-Methods属性
 config.addAllowedMethod("*");
 // 设置允许的header
 // Response Headers里面的Access-Control-Allow-Headers属性,这里是Access-Control-Allow-Headers: content-type, headeruserid, headerusertoken
 config.addAllowedHeader("*");
 // Response Headers里面的Access-Control-Max-Age:3600
 // 表示下回同一个接口post请求,在3600s之内不会发送options请求,不管post请求成功还是失败,3600s之内不会再发送options请求
 // 如果不设置这个,那么每次post请求之前必定有options请求
 config.setMaxAge(3600L);
 // 2. 为url添加映射路径
 UrlBasedCorsConfigurationSource corsSource = new UrlBasedCorsConfigurationSource();
 // /**表示该config适用于所有路由
 corsSource.registerCorsConfiguration("/**", config);
 // 3. 返回重新定义好的corsSource
 return new CorsFilter(corsSource);
 }
}

这里setMaxAge方法来设置预检请求(OPTIONS请求)的有效期,当浏览器第一次发送非简单的跨域POST请求时,它会先发送一个OPTIONS请求。如果服务器允许跨域,并且设置了Access-Control-Max-Age头(设置了setMaxAge方法),那么浏览器会缓存这个预检请求的结果。在Access-Control-Max-Age头指定的时间范围内,浏览器不会再次发送OPTIONS请求,而是直接发送实际的POST请求,不管POST请求成功还是失败,在设置的时间范围内,同一个接口请求是绝对不会再次发送OPTIONS请求的。

后端需要注意的是,我这里设置允许请求的方法是config.addAllowedMethod("*"),*表示允许所有HTTP请求方法。如果未设置,则默认只允许“GET”和“HEAD”。你可以设置的HTTPMethod为GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS, TRACE

经过我的测试,OPTIONS无需手动设置,因为单纯只设置OPTIONS也无效。如果你设置了允许POST,代码为config.addAllowedMethod(HttpMethod.POST); 那么其实已经默认允许了OPTIONS,如果你只允许了GET,尝试发送POST请求就会报错。

举个例子,这里只允许了GET请求,当我们尝试发送一个POST非简单请求,预检请求返回403,服务器拒绝了OPTIONS类型的请求,因为你只允许了GET,未配置允许OPTIONS请求,那么浏览器将收到一个403 Forbidden响应,表示服务器拒绝了该OPTIONS请求,POST请求的状态显示CORS error

在Spring Boot中,配置允许某个请求方法(如POST、PUT或DELETE)时,OPTIONS请求通常会被自动允许。这意味着在大多数情况下,后端开发人员不需要特意考虑OPTIONS请求。这种自动允许OPTIONS请求的行为取决于使用的跨域处理库或配置,最好还是显式地允许OPTIONS请求。

 

点击关注,第一时间了解华为云新鲜技术~

与从前后端的角度分析options预检请求相似的内容:

从前后端的角度分析options预检请求

options预检请求是干嘛的?options请求一定会在post请求之前发送吗?前端或者后端开发需要手动干预这个预检请求吗?不用文档定义堆砌名词,从前后端角度单独分析,大白话带你了解!

以前端视角,漫谈「云端」

当今世界,云计算技术在快速发展,不断为我们带来新的应用场景和解决方案。作为一名前端开发者,了解云技术并掌握如何在前端中应用它们是必不可少的。本篇文章将介绍云计算技术的基本概念,并从前端角度探讨如何使用云技术提高应用的可扩展性、安全性、性能和用户体验。

第三方App与Termux命令建立IO通道

第三方 App 调用 Termux 执行命令基本实现,但是 bash、awk、clangd 这类命令可以从标准输入读取信息并维持运行,Termux 第三方调用缺乏有效支持。了解安卓的 IPC 机制,建立Termux 命令与第三方 App 的 TCP/Socket 连接,最终实现前后端的持续通信。

vivo 低代码平台【后羿】的探索与实践

本文主要从前后端分离的低代码方案、自研高性能渲染引擎、高效的可视化配置方案、千亿级内容投放、低代码如何与传统开发共存等五个维度vivo在低代码平台方面的实践经验,其中也会涉及到动态交互如何运用低代码来编排和我们在提高配置效率方面的全面探索。

我的第一个项目(五):(前后端)注册用户名查重

好家伙, bug终究还是来了,而且是很离谱的bug 来吧,发现问题,再解决问题 1.注册无法检测到用户名重复 也就是说一个用户名可无限注册, 来看bug(。。。) (看来是后端验证逻辑出了问题) 要是这么上线估计直接寄了 2.完成注册用户名查重 大概率是后端出了问题 这里我们先去看看后端,从后端去改

Velocity 不用愁!Velocity 系统的前端工程化之路

Velocity是一个基于Java的Web页面模版引擎。十多年前,Velocity将Java代码从Web页面中分离出来,使得开发者能够并行网页开发和Java开发。随着十年前后端分离的浪潮涌动,回首再面对这些基于Velocity的旧系统,无论是后端还是前端人员维护,都会存在诸多问题

Svelte框架实现表格协同文档

本文由葡萄城技术团队于博客园原创并首发 转载请注明出处:葡萄城官网,葡萄城为开发者提供专业的开发工具、解决方案和服务,赋能开发者。 首先,从框架搭建上,本篇示例采用当下流行的前后端分离的开发方式,前端使用npm作为脚手架搭建Svelte框架。 后端使用Java的SpringBoot作为后端框架。 首

芯片产业管理和营销指北(1)—— 产品线经理主要职能

注意:本文是依据 俞志宏 老师的 《我在硅谷管芯片:芯片产品线经理生存指南》 一书阅读后归纳总结得到。可以试做此书的读后感,对芯片产业感兴趣的同僚强烈推荐此书 产品线负责人(产品线经理):负责从芯片市场需求开始,经历芯片的产品定义、芯片的前端和后端设计、工艺制定、供应商制定、软件设计(对于数字芯片)

各开发语言DNS缓存配置建议

作者:翟贺龙 一、背景 在计算机领域,涉及性能优化动作时首先应被考虑的原则之一便是使用缓存,合理的数据缓存机制能够带来以下收益: 1.缩短数据获取路径,热点数据就近缓存以便后续快速读取,从而明显提升处理效率; 2.降低数据远程获取频次,缓解后端数据服务压力、减少前端和后端之间的网络带宽成本; 从 C

从0到1构建基于自身业务的前端工具库

在实际项目开发中无论 M 端、PC 端,或多或少都有一个 utils 文件目录去管理项目中用到的一些常用的工具方法,比如:时间处理、价格处理、解析url参数、加载脚本等,其中很多是重复、基础、或基于某种业务场景的工具,存在项目间冗余的痛点以及工具方法规范不统一的问题