什么是预检请求？CORS OPTIONS 检查说明

什么是预检请求？

预检请求是浏览器在某些跨源请求之前自动进行的 CORS 检查。预检请求识别调用者的来源、预期方法和非安全列表请求字段名称。服务器的响应告诉浏览器是否可以发送实际请求；预检不执行该预期的应用操作。

有用的定义包括机制及其边界。预检请求影响交换的特定部分，而相邻的责任仍然属于 HTTP、浏览器、选定的传输、应用程序或服务器的数据模型。将这些层保持分开使得错误报告可以重现，并防止配置更改被误认为是访问控制决策。

对于 API 开发者，第一个问题是谁创建值或行为。下一个问题是谁解释它。最后一个问题是什么可观察的结果证明解释成功。那三个答案将一个术语转变为一个可测试的接口合同。

实际请求前的 OPTIONS 检查

浏览器根据其方法、作者控制的字段和内容类型对跨源获取进行分类。如果请求超出了 CORS 安全列表的形状，浏览器将创建一个 OPTIONS 请求到目标 URL，而不是立即发送应用程序方法。

Origin 标识调用页面。Access-Control-Request-Method 命名计划的方法，Access-Control-Request-Headers 列出相关的非安全列表字段名称。预检请求不携带实际请求主体，正常的 Fetch 规则表示 CORS 预检请求排除凭据。

服务器或网关返回 Access-Control-Allow-Origin 以及涵盖预期交换的方法和字段权限。还可以返回 Access-Control-Max-Age，以便浏览器在实施限制内缓存成功的预检结果。

只有在策略匹配后，浏览器才发送实际请求。第二个响应也必须携带适当的 CORS 权限。通过 OPTIONS 但省略实际响应上的字段仍然会导致浏览器可见的失败。

读取预检对

以下术语分隔了通常合并成一个标签的组件。将它们视为参与者之间的接口，而不是网络跟踪中的装饰。

为什么预检请求在网络数据收集中的重要性

预检请求可以改变到达的字节、这些字节的解释方式，或浏览器代码是否可以观察到结果。在改变工具之前，收集工作流应该确定这种影响。记录请求的 URL、最终 URL、响应状态、表示类型、相关协议字段和一个预期的内容标记。这个紧凑的记录区分了一个正确的页面与访问消息、同意屏幕、重定向目标、空应用程序外壳或不兼容编码。

直接 HTTP 是最简单的获取路径，当所需数据存在于开放的服务器渲染的响应中时。浏览器在满足批准的内容依赖于 JavaScript 执行、浏览器管理的状态、导航或浏览器安全策略时变得相关。这两条路径不应该强制看起来完全相同：浏览器根据平台规则管理 cookies、压缩、重定向、CORS 和存储，而直接客户端则暴露不同的默认设置。

会话连续性在回应建立下一个请求的状态时很重要。将授权序列保持在一个有限的客户端上下文内，保留所需的区域和网络来源，并避免混合来自不相关工作的状态。代理更改网络来源；它不复生头信息，解码表示，执行脚本或授予对受限内容的访问。

解析仅在表示验证后开始。在提取字段之前确认最后的主机、规范身份（如可用）、媒体类型、解码状态和所需的业务标记。这个顺序防止解析器将错误文档变成看起来技术上成功的空记录。

中介支持明确关注。内容交付网络可以选择编码变体，网关可以回答OPTIONS，缓存可以重用协商的响应，而应用服务器可以设置cookie或授权字段。仅比较应用代码与最终页面输出跳过了可能做出决策的层。

无抓取的通用抓取API在团队需要管理检索允许的公共内容时相关，包括JavaScript渲染的页面。获取合同仍应定义目标、允许的字段、预期的表示、接受标记和停止条件。产品能力并不能替代源条款、隐私审查或应用级别验证。

常见触发预检的请求

当预检请求改变具体产品行为、兼容性要求或诊断决策时，它在架构中占有一席之地。这些用例首先描述工作，然后描述协议特性。

预检和CORS白名单请求

预检请求属于HTTP的一个层，不应与相邻层混淆。一个健全的实现识别出哪个组件选择值，哪个组件可以更改它，以及什么证据证明最终表示是正确的。

只有在保留层边界的情况下，比较才有意义。两个机制可以共存于一个请求中，替换一个并不自动替换另一个。以输入、可观察输出、失败状态和所有权的术语记录所选行为。

为什么预检处理会中断

• 将OPTIONS路由到无处理程序。 网关和框架可以在应用CORS逻辑运行之前返回一个通用错误。
• 允许方法但不允许字段。 计划的方法和每个请求的非白名单字段必须得到涵盖。
• 在OPTIONS上要求普通凭据。 获取预检行为不包括正常请求凭据。
• 忘记实际响应。 权限检查和后续响应都需要适用的来源政策。
• 仅调试服务器应用程序日志。 CDN、代理或网络服务器可能会在应用程序看到之前回答OPTIONS请求。
• 禁用必要的请求字段。 删除安全性或内容字段以避免预检可能会损害API合同。

在删除所有对库或浏览器自动操作的假设后，大多数故障更容易诊断。记录最小的跟踪，编辑机密信息，并逐个更改受控变量。目标是对返回表示的稳定解释，而不是一系列不相关的头部调整。

预检失败清单

该顺序在启动之前作为设计审查，在行为变化之后作为生产诊断。它将协议证据与应用程序结果保持相关联。

1. 识别页面来源、目标来源、计划的方法、内容类型和作者控制的字段。
2. 打开OPTIONS交换，读取其状态和响应字段，而不假设应用程序已处理它。
3. 根据凭证规则将Access-Control-Allow-Origin与请求来源匹配。
4. 确认Access-Control-Allow-Methods包括计划的方法。
5. 确认Access-Control-Allow-Headers覆盖每个请求的非安全列字段名称。
6. 检查重定向、代理和错误处理程序，以查找省略CORS字段的响应。
7. 在OPTIONS通过后，检查实际请求和响应，作为一个单独的交换。

通过保存一个小的接受样本和一个拒绝样本，以及相同的编辑规则来完成审核。未来的更改可以与已知的页面身份、预期字段和解码内容进行比较，而不是仅仅依靠记忆或截图。

预检请求的安全性和可观察性

预检请求参与一个可以跨越浏览器、网关、缓存和源服务器的请求路径。每个跳转只应接受它理解的值，保留必须生存的字段，并避免将凭据或个人数据复制到日志中。协议语法并不是授权。

操作记录应捕获请求的URL、最终URL、状态、表示类型、相关字段名称和有界内容标记。完整的主体和凭证值在常规诊断中很少需要，并可能导致不必要的保留风险。

浏览器行为和直接HTTP行为是不同的测试表面。CORS、Cookie存储、自动解压缩和重定向处理可能在应用程序代码看到结果之前由浏览器或库执行。比较捕获时记录客户端及其默认设置。

定义预检请求的标准

Fetch标准预检算法 定义浏览器的策略检查。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在选定的客户端和部署中观察。

MDN的预检请求术语表 显示OPTIONS请求字段。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在选定的客户端和部署中观察。

MDN的CORS指南 解释预检和凭证约束。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在选定的客户端和部署中观察。

HTTP OPTIONS语义 定义底层HTTP方法。这个主要来源修正了本文中使用的词汇和边界，而实现行为仍需在选定的客户端和部署中观察。

预检调试规则

将预检和实际请求视为两个独立的HTTP交换，并在产生每个响应的层上验证来源、方法、字段、凭证、网关和最终响应行为。

将该规则纳入接受测试。说明哪个参与者发送信号，哪个参与者解释信号，哪些中介可以更改路径，以及哪个内容标记证明成功。这使预检请求成为可观察系统的一部分，而不是在失败后附加的标签。

参考文献

• Scrapeless通用抓取API文档
• Scrapeless通用抓取API产品概述
• Scrapeless关于标头、Cookie、会话和表示验证的指南
• Scrapeless在GitHub上