【转】前端 | 浅谈预检请求

本文解析了为什么会出现预检请求及其实现机制。介绍了预检请求的目的、触发条件及其如何工作,帮助理解跨域请求的工作原理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

近期在项目中发现浏览器发出的接口请求有时候会调用两次,第一次返回204且没有数据,第二次返回200有数据。十分不解,

查了一下资料,原来是由于预检测请求,相关资料如下:


转载文章:https://blog.youkuaiyun.com/u012496505/article/details/78011344 感谢作者的详细解释。

image.png

背景

不知道大家有没有发现,有时候我们在调用后台接口的时候,会请求两次,如下图的

图一.png

其实第一次发送的就是preflight request(预检请求),那么这篇文章将讲一下,为什么要发预检请求,什么时候会发预检请求,预检请求都做了什么

一. 为什么要发预检请求

我们都知道浏览器的同源策略,就是出于安全考虑,浏览器会限制从脚本发起的跨域HTTP请求,像XMLHttpRequest和Fetch都遵循同源策略。 
浏览器限制跨域请求一般有两种方式: 
1. 浏览器限制发起跨域请求 
2. 跨域请求可以正常发起,但是返回的结果被浏览器拦截了

一般浏览器都是第二种方式限制跨域请求,那就是说请求已到达服务器,并有可能对数据库里的数据进行了操作,但是返回的结果被浏览器拦截了,那么我们就获取不到返回结果,这是一次失败的请求,但是可能对数据库里的数据产生了影响。

为了防止这种情况的发生,规范要求,对这种可能对服务器数据产生副作用的HTTP请求方法,浏览器必须先使用OPTIONS方法发起一个预检请求,从而获知服务器是否允许该跨域请求:如果允许,就发送带数据的真实请求;如果不允许,则阻止发送带数据的真实请求。

二. 什么时候发预检请求

HTTP请求包括: 简单请求 和 需预检的请求

1. 简单请求

简单请求不会触发CORS预检请求,“简属于 
单请求”术语并不属于Fetch(其中定义了CORS)规范。 
若满足所有下述条件,则该请求可视为“简单请求”: 
- 使用下列方法之一: 
GET 
HEAD 
POST 
Content-Type: (仅当POST方法的Content-Type值等于下列之一才算做简单需求) 
text/plain 
multipart/form-data 
application/x-www-form-urlencoded

注意: WebKit Nightly 和 Safari Technology Preview 为Accept 
Accept-Language 
, 和 Content-Language 
首部字段的值添加了额外的限制。如果这些首部字段的值是“非标准”的,WebKit/Safari 就不会将这些请求视为“简单请求”。WebKit/Safari 并没有在文档中列出哪些值是“非标准”的,不过我们可以在这里找到相关讨论:Require preflight for non-standard CORS-safelisted request headers Accept, Accept-Language, and Content-LanguageAllow commas in Accept, Accept-Language, and Content-Language request headers for simple CORS, and Switch to a blacklist model for restricted Accept headers in simple CORS requests。其它浏览器并不支持这些额外的限制,因为它们不属于规范的一部分。

2.需预检的请求

“需预检的请求”要求必须首先使用OPTIONS方法发起一个预检请求到服务区,以获知服务器是否允许该实际请求。“预检请求”的使用,可以避免跨域请求对服务器的用户数据产生未预期的影响。

当请求满足下述任一条件时,即应首先发送预检请求: 
- 使用了下面任一 HTTP 方法: 
PUT 
DELETE 
CONNECT 
OPTIONS 
TRACE 
PATCH 
- 人为设置了对 CORS 安全的首部字段集合之外的其他首部字段。该集合为: 
Accept 
Accept-Language 
Content-Language 
Content-Type 
DPR 
Downlink 
Save-Data 
Viewport-Width 
Width 
Content-Type的值不属于下列之一: 
application/x-www-form-urlencoded 
multipart/form-data 
text/plain

如下是一个需要执行预检请求的HTTP请求:

var invocation = new XMLHttpRequest();
var url = 'http://bar.other/resources/post-here/';
var body = '<?xml version="1.0"?><person><name>Arun</name></person>';

function callOtherDomain(){
  if(invocation)
    {
      invocation.open('POST', url, true);
      invocation.setRequestHeader('X-PRODUCT', 'H5');
      invocation.setRequestHeader('Content-Type', 'application/xml');
      invocation.onreadystatechange = handler;
      invocation.send(body); 
    }
}


......
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17

上面的代码使用POST请求发送一个XML文档,该请求包含了一个自定义的首部字段(X-PRODUCT:H5)。另外,该请求的Content-Typeapplication/xml。因此,该请求需要首先发起“预检请求”。 
image.png

 OPTIONS /resources/post-here/ 
 HTTP/1.1
 Host: bar.other
 User-Agent: Mozilla/5.0 (Macintosh; U; 5.Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-us,en;q=0.5
 Accept-Encoding: gzip,deflate
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
 Connection: keep-alive
 Origin: http://foo.example
 Access-Control-Request-Method: POST
 Access-Control-Request-Headers: X-PINGOTHER, Content-Type




 HTTP/1.1 200 OK
 Date: Mon, 01 Dec 2008 01:15:39 GMT
 Server: Apache/2.0.61 (Unix)
 Access-Control-Allow-Origin: http://foo.example
 Access-Control-Allow-Methods: POST, GET, OPTIONS
 Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
 Access-Control-Max-Age: 86400
 Vary: Accept-Encoding, Origin
 Content-Encoding: gzip
 Content-Length: 0
 Keep-Alive: timeout=2, max=100
 Connection: Keep-Alive
 Content-Type: text/plain
  • 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

从上面的报文中可以看到,第1~12行发送了一个使用OPTIONS方法的预检请求。 OPTIONS是HTTP/1.1协议中定义的方法,用以从服务器获取更多信息。该方法不会对服务器资源产生影响。遇见请求中同时携带了下面两个首部字段:

Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PRODUCT

  • 1
  • 2
  • 3
  • 4

首部字段 Access-Control-Request-Method 告知服务器,实际请求将使用 POST 方法。首部字段 Access-Control-Request-Headers 告知服务器,实际请求将携带两个自定义请求首部字段:X-PINGOTHER 与 Content-Type。服务器据此决定,该实际请求是否被允许。

第14~26行 为预检请求的响应,表明服务器将坚守后续的实际请求。重点看第17~20行:

Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • 1
  • 2
  • 3
  • 4

首部字段 Access-Control-Allow-Methods 表明服务器允许客户端使用 POST,GET 和 OPTIONS 方法发起请求。

首部字段Access-Control-Allow-Headers 表明服务器允许请求中携带字段X-PINGOTHER 与Content-Type。与 Access-Control-Allow-Methods一样,Access-Control-Allow-Headers的值为逗号分割的列表。

最后,首部字段

Access-Control-Max-Age 表明该响应的有效时间为 86400 秒,也就是 24 小时。在有效时间内,浏览器无须为同一请求再次发起预检请求。请注意,浏览器自身维护了一个最大有效时间,如果该首部字段的值超过了最大有效时间,将不会生效。

预检请求完成之后,发送实际请求:

POST /resources/post-here/ HTTP/1.1
Host: bar.other
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20081130 Minefield/3.1b3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
X-PINGOTHER: pingpong
Content-Type: text/xml; charset=UTF-8
Referer: http://foo.example/examples/preflightInvocation.html
Content-Length: 55
Origin: http://foo.example
Pragma: no-cache
Cache-Control: no-cache


<?xml version="1.0"?><person><name>Arun</name></person>




HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:40 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 235
Keep-Alive: timeout=2, max=99
Connection: Keep-Alive
Content-Type: text/plain


[Some GZIP'd payload]

  • 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
四.参考资料

https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS


<think>我们正在解决前端请求携带特殊Headers(如Authorization)时触发CORS预检请求失败的问题,特别是结合cpolar穿透的情况。回顾之前的讨论,我们知道预检请求(OPTIONS请求)失败会导致CORS错误。根据引用[1],错误信息可能是"Responsetopreflightrequestdoesn'tpassaccesscontrolcheck:ItdoesnothaveHTTPokstatus"。引用[3]提到,预检请求失败(OPTIONS405)是因为服务器没有正确处理OPTIONS方法。同时,引用[4]的流程图也说明了预检请求的流程。根本原因:当请求携带了自定义头部(如Authorization)时,浏览器会首先发送一个OPTIONS方法的预检请求。如果服务器未能正确处理这个OPTIONS请求(例如返回非2xx状态码或者缺少必要的CORS响应头),浏览器就会阻止实际请求。针对cpolar穿透的情况,我们需要确保:1.被代理的后端服务正确配置了CORS,特别是要处理OPTIONS请求。2.cpolar隧道配置要允许透传CORS相关的头部,并且不能干扰预检请求。具体解决步骤:一、后端服务配置1.确保后端服务能够正确处理OPTIONS请求。根据引用[3],我们需要在服务器端为OPTIONS请求返回正确的响应头,并且返回200状态码。不同后端框架的处理方式:-Express(Node.js):```javascript//处理OPTIONS请求app.options('/your-route',(req,res)=>{res.header('Access-Control-Allow-Origin','*');res.header('Access-Control-Allow-Methods','GET,POST,OPTIONS,PUT,DELETE');res.header('Access-Control-Allow-Headers','Authorization,Content-Type');res.sendStatus(200);});```或者使用中间件(如cors包):```javascriptconstcors=require('cors');app.use(cors());//默认配置允许所有跨域请求```-SpringBoot(Java):```java@ConfigurationpublicclassCorsConfigimplementsWebMvcConfigurer{@OverridepublicvoidaddCorsMappings(CorsRegistryregistry){registry.addMapping("/**").allowedOrigins("*").allowedMethods("GET","POST","PUT","DELETE","OPTIONS").allowedHeaders("Authorization","Content-Type").allowCredentials(false)//如果不需要凭证,可以设置为false.maxAge(3600);//预检请求缓存时间}}```或者使用过滤器:```java@ComponentpublicclassCorsFilterimplementsFilter{@OverridepublicvoiddoFilter(ServletRequestreq,ServletResponseres,FilterChainchain)throwsIOException,ServletException{HttpServletResponseresponse=(HttpServletResponse)res;HttpServletRequestrequest=(HttpServletRequest)req;response.setHeader("Access-Control-Allow-Origin","*");response.setHeader("Access-Control-Allow-Methods","GET,POST,PUT,DELETE,OPTIONS");response.setHeader("Access-Control-Allow-Headers","Authorization,Content-Type");if("OPTIONS".equalsIgnoreCase(request.getMethod())){response.setStatus(HttpServletResponse.SC_OK);}else{chain.doFilter(req,res);}}}```-FastAPI(Python):```pythonfromfastapiimportFastAPIfromfastapi.middleware.corsimportCORSMiddlewareapp=FastAPI()app.add_middleware(CORSMiddleware,allow_origins=["*"],allow_methods=["*"],allow_headers=["*"],)```注意:在生产环境中,请将`allow_origins`设置为具体的域名。2.确保在响应中包含了必要的CORS头,特别是`Access-Control-Allow-Headers`要包含`Authorization`(以及前端可能发送的其他自定义头)。二、cpolar隧道配置在cpolar的配置文件(如cpolar.yml)中,需要确保隧道配置不会阻止OPTIONS请求,并且能够透传CORS相关的头部。例如:```yamltunnels:your-tunnel-name:proto:httpaddr:8080#本地服务端口host_header:rewriteresponse_headers:Access-Control-Allow-Origin:"*"Access-Control-Allow-Methods:"*"Access-Control-Allow-Headers:"Authorization,Content-Type"```注意:`host_header:rewrite`是为了让后端服务能够接收到正确的主机头。三、前端注意事项前端在发送请求时,如果携带了`Authorization`头,浏览器会自动发起预检请求。我们无需在前端做特别处理,但需要确保后端和隧道配置正确。四、调试技巧1.使用浏览器开发者工具查看网络请求,特别关注OPTIONS请求的响应状态码和响应头。2.使用curl命令测试预检请求:```bashcurl-XOPTIONS"http://your-cpolar-domain"\-H"Origin:http://your-frontend-domain"\-H"Access-Control-Request-Method:POST"\-H"Access-Control-Request-Headers:authorization,content-type"\-v```检查返回的响应头是否包含`Access-Control-Allow-Headers:authorization,...`以及状态码是否为200。五、安全提示1.在生产环境中,不要使用`Access-Control-Allow-Origin:*`,而应该设置为具体的域名。2.如果前端需要发送凭证(如cookies),则`Access-Control-Allow-Origin`不能使用通配符`*`,而必须指定域名,并且后端要设置`Access-Control-Allow-Credentials:true`。通过以上步骤,应该能够解决前端请求携带Authorization头导致的CORS预检请求失败问题。相关问题:1.如何为特定的路由配置CORS规则?2.在SpringSecurity中如何配置CORS?3.如何解决CORS预检请求的缓存问题?4.如何在Nginx中配置CORS?</think> 以下是针对**前端请求携带 `Authorization` 头部时触发 CORS 预检失败**的完整解决方案,结合 cpolar 穿透的特性: --- ### 一、问题核心原因 当请求携带 `Authorization` 等自定义 Header 时,浏览器会触发 **OPTIONS 预检请求**。失败通常因为: 1. **后端未处理 OPTIONS 方法**(返回 405 错误)[^1][^3] 2. **缺失关键响应头**: ```http Access-Control-Allow-Headers: Authorization # 未声明允许自定义头 Access-Control-Allow-Methods: POST, OPTIONS # 未声明允许的 HTTP 方法 ``` 3. **cpolar 隧道未透传 CORS 头**(拦截了服务端返回的 CORS 头) --- ### 二、解决方案 #### ✅ 第一步:后端显式处理 OPTIONS 请求 ▸ **Node.js/Express**(必需): ```javascript // 显式处理 OPTIONS 预检请求 app.options('/api', (req, res) => { res.header('Access-Control-Allow-Origin', '*') res.header('Access-Control-Allow-Methods', 'GET, POST, OPTIONS') res.header('Access-Control-Allow-Headers', 'Authorization, Content-Type') // 关键! res.sendStatus(200) }) ``` ▸ **Python/FastAPI**(使用 CORSMiddleware)[^3]: ```python app.add_middleware( CORSMiddleware, allow_headers=["Authorization", "Content-Type"], # 明确允许 Authorization allow_methods=["*"] ) ``` #### ✅ 第二步:配置 cpolar 透传 CORS 头 在 `cpolar.yml` 中增加: ```yaml tunnels: my-service: addr: 8080 proto: http response_headers: Access-Control-Allow-Headers: "Authorization, Content-Type" # 透传自定义头 Access-Control-Allow-Methods: "GET, POST, OPTIONS" # 透传方法 rewrite_host: true # 确保 Host 头不被修改 ``` #### ✅ 第三步:前端检查请求规范 确保请求符合 **简单请求规则**,否则必然触发预检: ```javascript // 正确示例(显式声明 Content-Type) fetch('https://your-cpolar-domain/api', { method: 'POST', headers: { 'Authorization': 'Bearer xxxx', 'Content-Type': 'application/json' // 非简单请求头,必须显式声明 }, body: JSON.stringify({data: 'test'}) }) ``` --- ### 三、调试流程 1. **检查 OPTIONS 请求响应**: - 在浏览器 Network 标签中查看 OPTIONS 请求的响应状态码(需 200)[^1] - 验证响应头包含: ```http Access-Control-Allow-Headers: Authorization Access-Control-Allow-Methods: POST, OPTIONS ``` 2. **通过 curl 测试预检**: ```bash curl -X OPTIONS "http://your-cpolar-domain" \ -H "Origin: http://your-frontend.com" \ -H "Access-Control-Request-Headers: authorization" \ -H "Access-Control-Request-Method: POST" --verbose ``` 检查返回头是否包含 `Access-Control-Allow-Headers: authorization` --- ### 四、终极备选方案 若仍无法解决(如后端不可修改): #### 方案 A:Nginx 反向代理(同源规避) ```nginx location /api { proxy_pass http://backend-server:8080; # 将跨域请求为同源 add_header Access-Control-Allow-Headers "Authorization"; # 添加 CORS 头 } ``` #### 方案 B:JSONP(仅限 GET 请求) ```html <script> function handleAuth(data) { console.log("跨域数据:", data); } </script> <script src="https://api-domain.com/data?callback=handleAuth"></script> ``` > ⚠️ 安全提示:生产环境必须替换 `allow_origins: ["*"]` 为具体域名,否则会导致安全风险[^3][^4] --- ###
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值