浏览器中的preflight请求-预检请求

本文详细解释了CORS预检请求的触发条件、作用机制,以及如何在服务器端进行配置。重点讲解了预检请求的触发场景和必要性,包括自定义请求头引发的预检过程。
什么是preflight请求?

preflight,一个cors预检请求,属于options请求。该请求会在浏览器认为即将要执行的请求可能会对服务器造成不可预知的影响时,由浏览器自动发出。
利用预检请求,浏览器能够知道当前的服务器是否允许执行即将要进行的请求,只有获得了允许,浏览器才会真正执行接下来的请求。
所以,总结有几点:

  • 浏览器自动发出该请求,不需要用户干预
  • 该请求发生在用户发送的请求之前,只有预检请求通过,用户发送的请求才能发送到服务器,否则抛出CORS错误。

prefilght触发条件

preflight预检请求属于cors规范的一部分,是一种服务器验证机制。目前所有浏览器都实现了该规范,但是不免有些浏览器会对规范内容进行扩充。但是必须实现的规范是:只有以下条件满足的情况下才不会发送预检请求,否则会在发送用户请求之前发送预检请求,以免在获得允许之前对服务器产生不可预知的影响。
条件有:

  1. 请求方法限制

只能使用GET、POST方法

  1. 请求头限制

只能包含九种请求头:

  • Accept
  • Accept-language
  • Content-Language
  • Content-Type
  • DPR
  • Downlink
  • Save-Data
  • Viewport-Width
  • Width
  1. Content-type限制

只能包含三种类型:

  • text/plain
  • multipart/form-data
  • application/x-www-form-urlencoded
  1. XMLHttpRequestUpload对象限制

该对象没有注册任何事件监听器

  1. ReadableStream对象限制

请求中不能使用ReadableStream对象

如果以上条件有一条不满足,浏览器则会自动发起预检请求

配置preflight请求

浏览器自动发送的预检请求,一般采用三个字段来表示:

  • Origin:表示当前请求的访问来源(域名)
  • Access-Control-Request-Headers:告知服务器实际请求所携带的自定义首部字段
  • Access-Control-Request-Methods:告知服务器实际请求所使用的 HTTP 方法

服务器基于从预检请求获得的信息来判断,是否接受接下来的实际请求。

所以服务器同时需要配置preflight响应来回应浏览器,告知浏览器是否接受预检请求,主要涉及到三个字段:

  • Access-Control-Allow-Origin: 表示允许的访问来源。或者可以使用"*" 表示允许所有的访问来源。这个字段一般用于对跨域请求的支持。
  • Access-Control-Allow-Headers:表示允许的自定义请求头。
  • Access-Control-Allow-Methods:表示允许的请求方式。

举一个例子:

客户端自定义了一个请求头uname,内容是admin。但是此时服务器端并没有预检请求的处理(这里使用node作为服务器端)

客户端:
在这里插入图片描述

服务器(由于是不同域,所以实现处理了跨域请求):
在这里插入图片描述

结果:
在这里插入图片描述

可以看到在发送用户请求http://127.0.0.1:8000/server之前,浏览器先发送了一个预检请求,Type=preflight,而触发预检请求的原因是:客户端在请求头中添加了自定义请求头。但是由于服务器端没有预检请求的处理,所以浏览器没有得到预检请求的响应,就不会处理用户本身要发送的请求,因此可以看到/server这个请求出现了CORS ERROR

按照之前所理解的预检请求,我们可以在服务器端进行配置对该请求的响应:

app.use('/server', (req,res,next) => {
    // 设置所有域都可以访问该域的资源
    res.setHeader('Access-Control-Allow-Origin','*');
    // 设置允许的自定义请求头
    res.setHeader('Access-Control-Allow-Headers', 'uname');
    next();
})

app.post('/server',(req,res) => {
    res.send('post');
})

注意:由于preflight请求属于cors规范的一部分,因此当前仅当跨域的情况下可能会触发preflight。也即:只有跨域了,且不满足之前触发条件中一条就会触发预检请求。没有跨域,不会触发预检请求。

<think>浏览器在发送预检请求(OPTIONS)时不携带Authorization头是由CORS(跨域资源共享)规范和安全策略决定的。以下是详细解释: ### 原因分析 1. **预检请求的本质**: - 预检请求浏览器自动发起的OPTIONS请求,用于检查实际请求是否安全 - 它的目的是询问服务器:"是否允许实际请求携带这些自定义头和凭证?" 2. **安全机制**: - 如果预检请求携带了凭证信息(如Authorization头),可能会将这些敏感信息泄漏到未经验证的服务器 - CORS规范要求预检请求必须是"简单请求",不能包含任何认证信息 3. **规范要求**: - 根据[Fetch标准](https://fetch.spec.whatwg.org/#cors-preflight-fetch): > "A CORS preflight request must not include any credentials" - 这意味着预检请求中禁止包含: - `Authorization` 头 - Cookies - TLS客户端证书 4. **工作流程**: ```mermaid sequenceDiagram Browser->>Server: OPTIONS预检请求(无凭证) Server-->>Browser: 返回CORS策略(允许的源/方法/头/凭证) Browser->>Server: 实际请求(携带Authorization头) ``` ### 为什么控制台显示"预配标头"才有认证信息? 1. **请求分阶段**: - 阶段1:OPTIONS预检(无凭证) - 阶段2:实际请求(带凭证) 2. **开发者工具显示**: - 浏览器开发者工具通常将这两个请求分开显示 - 预检请求(OPTIONS)的请求头中不会出现Authorization - 实际请求请求头中才会出现Authorization ### 解决方案建议 即使预检请求不携带Authorization头,也可以通过以下方式保证认证流程: #### 服务器端配置 服务器必须在预检响应中明确允许Authorization头: ```http Access-Control-Allow-Headers: Authorization Access-Control-Allow-Credentials: true ``` #### 客户端代码 确保在fetch请求中设置凭证模式: ```typescript fetch(url, { method: 'GET', headers: { 'Authorization': 'Bearer token123' // 实际请求才会携带 }, credentials: 'include' // 关键:启用凭据传输 }); ``` ### 特殊场景处理 对于需要预检的认证请求,典型流程: 1. 第一次OPTIONS预检(无Authorization) 2. 服务器响应允许Authorization头 3. 浏览器发送实际请求(携带Authorization) 4. 服务器验证并返回数据 ### 异常情况处理 如果遇到预检失败,检查: 1. 服务器是否正确处理OPTIONS方法 2. 响应头是否包含 `Access-Control-Allow-Headers: Authorization` 3. 是否配置 `Access-Control-Allow-Credentials: true` 4. 是否使用通配符`*`(使用凭证时不能使用`*`) §§相关问题§§: 1. 如何为需要认证的API设计免预检请求? 2. CORS规范中哪些头属于"简单请求头"? 3. 服务端如何区分预检请求和实际请求? 4. 使用Service Worker能否绕过CORS预检限制? </think># 为什么浏览器预检请求中不发送Authorization头 浏览器预检请求(OPTIONS请求)中不发送Authorization头是由CORS(跨域资源共享)规范和安全机制决定的。下面是详细解释: ## 核心原因 1. **安全设计**: - 预检请求的核心目的是**安全验证**,而不是实际数据传输 - 发送Authorization头会暴露敏感凭证信息到未经验证的服务器 - 防止恶意网站窃取用户凭证 2. **规范要求**: - 根据W3C的CORS规范,预检请求必须是"匿名请求" - 规范明确指出预检请求不应包含任何用户凭证 - [Fetch Standard
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值