HTTP OPTIONS 方法详解：从原理到实践
本文深入剖析 HTTP OPTIONS 方法的核心作用、CORS 预检机制及实际应用场景，帮助开发者彻底解决跨域问题
一、OPTIONS 方法概述
1.1 基本定义
OPTIONS 是 HTTP/1.1 协议定义的请求方法之一，用于获取目标资源支持的通信选项。其主要特点：
- 安全方法：不会修改服务器资源状态
- 幂等方法：多次调用效果相同
- 元数据查询：获取资源支持的操作信息
1.2 核心目的
| 场景 | 说明 |
|---|---|
| 服务器能力查询 | 获取目标 URL 支持的 HTTP 方法 |
| CORS 预检请求 | 浏览器自动发起的跨域权限检查 |
| API 发现 | 探索服务器支持的操作（较少使用） |
OPTIONS /api/user HTTP/1.1
Host: example.com
Origin: https://client-site.com
二、核心应用：CORS 预检机制
2.1 什么是 CORS？
跨域资源共享（CORS） 是浏览器的安全机制，限制不同源（协议+域名+端口）的资源交互。
2.2 为什么需要预检请求？
浏览器对非简单请求要求预先获得服务器授权，避免意外操作服务器资源。
2.3 预检触发条件（满足任一即触发）
| 类别 | 具体条件 |
|---|---|
| HTTP 方法 | PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH |
| 自定义头部 | Authorization, X-Custom-Header 等非标准头 |
| Content-Type | application/json, text/xml 等非简单类型 |
2.4 预检请求流程
sequenceDiagram浏览器->>目标服务器: OPTIONS 预检请求note over 浏览器: 包含：<br>Origin<br>Access-Control-Request-Method<br>Access-Control-Request-Headers目标服务器->>浏览器: 预检响应note over 目标服务器: 包含：Access-Control-Allow-* 系列头部alt 预检通过浏览器->>目标服务器: 发送实际请求 (POST/PUT 等)目标服务器->>浏览器: 返回实际数据else 预检失败目标服务器->>浏览器: 阻断请求并报 CORS 错误end
三、简单请求 vs 预检请求
3.1 简单请求特点
GET /data HTTP/1.1
Host: api.example.com
Origin: https://client.com
Accept: text/html
| 特征 | 允许值 |
|---|---|
| 方法 | GET, HEAD, POST |
| 头部 | Accept, Accept-Language, Content-Language |
| Content-Type | application/x-www-form-urlencoded multipart/form-data text/plain |
3.2 处理流程对比
| 简单请求 | 预检请求 | |
|---|---|---|
| 请求次数 | 1 次 | 2 次 (OPTIONS + 实际请求) |
| 浏览器行为 | 直接发送实际请求 | 先发送 OPTIONS 探路 |
| 权限检查点 | 响应中的 Access-Control-Allow-Origin | OPTIONS 响应中的 CORS 头部 |
| 性能影响 | 小 | 较大（增加 RTT 延迟） |
四、关键头部字段详解
4.1 预检请求头
| 头部 | 示例值 | 说明 |
|---|---|---|
| Origin | https://client.com | 请求来源 |
| Access-Control-Request-Method | POST | 实际请求方法 |
| Access-Control-Request-Headers | X-API-Key, Content-Type | 实际请求携带的头部 |
4.2 预检响应头
| 头部 | 示例值 | 说明 |
|---|---|---|
| Access-Control-Allow-Origin | https://client.com | 允许的源（或 *） |
| Access-Control-Allow-Methods | GET, POST, PUT | 允许的方法 |
| Access-Control-Allow-Headers | Authorization, Content-Type | 允许的头部 |
| Access-Control-Max-Age | 86400 | 预检缓存时间（秒） |
| Access-Control-Allow-Credentials | true | 是否允许携带凭证 |
4.3 标准 OPTIONS 响应
HTTP/1.1 200 OK
Allow: GET, POST, OPTIONS
Accept-Patch: application/json
Accept-Post: application/json
五、OPTIONS 的其他用途
5.1 服务器能力发现
OPTIONS * HTTP/1.1
Host: api.example.comHTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Accept: application/json
Accept-Charset: utf-8
5.2 HTTP/2 连接检查
在 HTTP/2 中可作为连接活性检查的替代方案
5.3 调试工具
开发人员手动测试服务器配置：
curl -X OPTIONS -H "Origin: http://test.com" -H "Access-Control-Request-Method: PUT" https://api.example.com -I
六、最佳实践与常见问题
6.1 服务器配置建议
# Nginx 配置示例
location /api/ {if ($request_method = 'OPTIONS') {add_header 'Access-Control-Allow-Origin' '*';add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type';add_header 'Access-Control-Max-Age' 86400;return 204;}
}
6.2 常见 CORS 错误解决
- 预检响应缺少头部：确保服务器返回必需的
Access-Control-Allow-*头部 - 凭证模式不匹配：带
credentials: include时需设置Access-Control-Allow-Credentials: true - 缓存问题：合理设置
Access-Control-Max-Age减少预检请求
6.3 性能优化
- 对静态资源设置较长的
Access-Control-Max-Age - 避免不必要的自定义头部
- 尽可能使用简单请求
七、总结
- OPTIONS 核心作用：CORS 预检请求的载体，确保跨域安全
- 浏览器自动处理：开发者无需手动发送 OPTIONS 请求
- 简单请求直通：符合特定条件的 GET/POST 可跳过预检
- 服务器配置关键：正确设置 CORS 响应头解决跨域问题
- 调试工具：通过 OPTIONS 请求检查服务器配置
理解 OPTIONS 方法的工作原理，是解决前端跨域问题和构建安全 API 服务的必备知识。掌握本文内容，您将能游刃有余地处理各种 CORS 相关场景。
参考
- https://blog.csdn.net/weixin_50882748/article/details/148672598
 - 详解)
