摘要：2026 年 6 月 16 日，互联网工程任务组（IETF）正式发布 RFC 10008 标准文档，定义了一种全新的 HTTP 请求方法——QUERY。该方法属于互联网标准跟踪文档（Standards Track），目前处于”提议标准”阶段。QUERY 方法填补了 GET 与 POST 之间长期存在的语义空白：它允许在请求体中携带复杂查询参数（类似 POST），但语义上被明确定义为”安全”（safe）且”幂等”（idempotent）（类似 GET），为 Web 开发者和 API 设计者提供了标准化的只读查询方案。本文梳理 RFC 10008 的核心要点，并从企业 API 安全与运维视角给出落地建议。
一、RFC 10008 核心信息速览
| 字段 | 内容 |
|---|---|
| 文档编号 | RFC 10008 |
| 标题 | The HTTP QUERY Method |
| 发布机构 | IETF（互联网工程任务组） |
| 发布日期 | 2026 年 6 月 16 日（当地时间） |
| 标准类别 | Standards Track（标准跟踪文档） |
| 当前阶段 | Proposed Standard（提议标准） |
| 编写方 | IETF HTTP 工作组 |
| 方法语义 | safe（安全）+ idempotent（幂等） |
| 请求体 | 支持（查询参数放 body，不在 URL 中） |
二、为什么需要 QUERY 方法？GET 和 POST 的”尴尬地带”
普通用户浏览网页时感知不到 HTTP 方法，但它们在浏览器、App、API、包管理器、命令行工具和各类 Web 服务的底层始终在运转。传统 HTTP 方法各司其职：
| 方法 | 用途 | 语义 |
|---|---|---|
GET | 请求数据 | 安全、幂等 |
POST | 提交数据 | 不安全、不幂等 |
PUT | 更新资源 | 不安全、幂等 |
PATCH | 部分更新 | 不安全、不幂等 |
DELETE | 删除资源 | 不安全、幂等 |
然而，当 API 需要向服务器发送一个结构复杂的查询，同时只想获取数据、不产生副作用时，开发者此前只能面对两种都不理想的选择。
选择一：GET 方法——参数受限于 URL
GET 适用于参数简单、可直接编码在 URL 中的查询。它语义明确、被广泛支持，但参数只能放在 URL 中。RFC 10008 中明确指出了这带来的多个困扰：
- URL 长度限制不明确：不同服务器、代理、浏览器对 URL 长度的限制各异，没有统一上限
- 结构化数据难以编码：嵌套 JSON、复杂过滤条件很难安全地编码到 URI 中
- 敏感信息泄露风险：请求 URI 可能被访问日志、浏览器历史、收藏夹、CDN 日志记录
- 缓存粒度失控：每一种不同的查询参数组合都会被视为一个独立资源，缓存效率低下
⚠️ 安全提示：将复杂查询参数拼在 URL 里，是 API 数据泄露的常见诱因之一。日志系统、APM 监控、CDN 边缘节点都可能留存这些 URL，一旦包含用户 ID、过滤条件等敏感字段，就构成了实质性的信息暴露。
选择二：借用 POST——语义模糊
POST 允许携带请求体，因此常被用于传递复杂查询条件（例如 POST /feed 配合表单数据）。然而，POST 在语义上并不承诺请求是只读的——它可能用于创建资源、更新数据、触发后台任务、提交表单，也可能仅仅用于执行一次搜索。
服务器无法从方法本身判断该请求是否安全、是否会改变状态。这带来的后果：
- WAF 规则难以精准拦截：安全设备无法区分”只读搜索”和”写入操作”，只能按 POST 的最高风险等级处理
- 重试机制存在风险：网络抖动时自动重试 POST 可能导致重复写入
- 缓存策略失效：POST 响应默认不可缓存，CDN 无法对只读查询结果做边缘缓存
- API 审计混乱：日志中无法从方法层面识别哪些请求是只读查询
三、QUERY 方法：语义与形式的最佳组合
QUERY 方法正是为弥合这一鸿沟而设计。
核心特征
| 维度 | GET | POST | QUERY |
|---|---|---|---|
| 请求体 | ❌ 不支持 | ✅ 支持 | ✅ 支持 |
| 语义安全 | ✅ 是 | ❌ 否 | ✅ 是 |
| 语义幂等 | ✅ 是 | ❌ 否 | ✅ 是 |
| 可缓存 | ✅ 是 | ❌ 否 | ✅ 是 |
| URL 参数 | ✅ 是 | ❌ 否 | ❌ 否（放 body） |
| 重试安全 | ✅ 是 | ❌ 否 | ✅ 是 |
使用方式
形式上接近 POST：查询参数放在请求体中，而非 URL 中，突破了 GET 的 URI 长度限制。
语义上接近 GET：被明确定义为”安全”（safe）且”幂等”（idempotent）的方法。QUERY 请求可以被自动重复或重试，而无需担心对服务器状态产生部分更改。
💡 幂等概念：幂等（idempotent）是数学与计算机学概念，常见于抽象代数。在 HTTP 语境下，指同一个请求执行一次与执行多次，对服务器状态产生的影响完全相同。
请求示例
http
QUERY /api/articles/search HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept-Query: application/json
{
"category": "security",
"tags": ["waf", "ddos"],
"date_range": {
"start": "2026-01-01",
"end": "2026-06-30"
},
"page": 1,
"size": 20
}
从此，开发者不再需要因为 GET 不够灵活而将只读操作”伪装”成 POST，API 设计的意图也因此更加清晰。
四、RFC 10008 规定的兼容机制
RFC 10008 不仅定义了 QUERY 方法本身，还详细规定了它与现有 HTTP 机制的兼容方式。
1. Allow 响应头：声明支持
服务器通过 Allow 响应头字段声明对 QUERY 方法的支持：
http
HTTP/1.1 200 OK
Allow: GET, POST, QUERY
2. Accept-Query 响应头：声明接受的查询格式
规范引入了新的 Accept-Query 响应头字段，告知客户端服务器接受哪些查询内容格式：
http
HTTP/1.1 200 OK
Accept-Query: application/json, application/x-www-form-urlencoded
3. 缓存机制
QUERY 响应支持缓存。代理服务器或处理器可以：
- 缓存查询结果
- 为其分配 URI 供后续通过 GET 方法访问
- 通过
Last-Modified、ETag等头部信息管理缓存有效性
4. 其他兼容性
文档还涵盖了以下议题：
- 媒体类型（Media Type）处理
- 重定向（Redirection）行为
- 条件请求（Conditional Requests）
- 范围请求（Range Requests）
- 安全相关考量（Security Considerations）
五、对企业 API 安全的 4 个实际价值
从企业运维和 API 安全视角看，QUERY 方法的落地带来以下实际价值：
1. WAF 规则可精准区分只读与写入
| 方法 | WAF 处理策略 |
|---|---|
GET / QUERY | 按只读处理，重点防 SQL 注入、参数篡改 |
POST / PUT / PATCH | 按写入处理，增加 CSRF、批量请求、频率限制 |
QUERY 方法让 WAF 能从方法层面识别只读查询，避免对只读搜索套用写入类的高风险拦截策略，减少误封。
2. 敏感查询参数不再进 URL
将复杂查询参数从 URL 转移到请求体，直接减少日志、监控、CDN 边缘节点的敏感信息留存面。
3. 只读查询可安全重试
QUERY 的幂等性保证了网络抖动时的自动重试不会产生副作用，降低微服务调用链中的重试风险。
4. CDN 边缘缓存可复用
QUERY 响应可缓存，CDN 可对高频只读查询做边缘缓存，减轻源站压力。
六、企业落地建议
RFC 10008 虽已获得 IETF 标准化批准并公开发布，但其”提议标准”身份意味着实际落地仍取决于各类 Web 服务器、代理、客户端、浏览器、API 平台及开发工具逐步增加支持。
短期（0-6 个月）
- 关注基础设施支持进度：Nginx、Apache、Cloudflare、AWS API Gateway 等对 QUERY 方法的支持时间表
- API 设计规范预留：在新 API 设计文档中加入 QUERY 方法的使用场景说明
- WAF 规则评估：评估现有 WAF 规则对未知 HTTP 方法的默认处理策略（是放行还是拦截）
中期（6-12 个月）
- 内部 API 试点：在内部微服务间试点 QUERY 方法
- 网关层适配：API 网关（Kong、APISIX、Envoy）增加 QUERY 路由支持
- 监控告警更新：日志、APM、安全监控增加 QUERY 方法的识别与统计
长期（12 个月+）
- 对外 API 迁移：将原本”POST 伪装只读查询”的接口逐步迁移到 QUERY
- CDN 缓存策略优化：利用 QUERY 的可缓存性优化边缘缓存
- 等保合规更新：在 API 安全策略文档中纳入 QUERY 方法的处理规范
⚠️ 主机吧提示：在基础设施未完整支持 QUERY 方法前，不要在生产环境强行启用。WAF、反向代理、负载均衡器对未知 HTTP 方法的默认行为可能是拒绝（405 Method Not Allowed）或异常转发，建议先在测试环境验证全链路兼容性。
七、FAQ 常见问题
Q1：QUERY 方法会取代 GET 和 POST 吗？
不会。QUERY 填补的是”需要请求体的只读查询”这一特定空白。简单查询继续用 GET，写入操作继续用 POST/PUT/PATCH，只有”复杂参数 + 只读语义”的场景才适合 QUERY。
Q2：浏览器什么时候支持 QUERY？
截至 RFC 10008 发布（2026 年 6 月），主流浏览器尚未原生支持 QUERY 方法。fetch() API 的支持需要浏览器厂商跟进实现。企业内部 API 和服务间调用可优先试点。
Q3：QUERY 请求会被 WAF 拦截吗？
可能。多数 WAF 默认只识别 GET/POST/PUT/DELETE 等传统方法，对未知方法可能按”可疑请求”处理。启用 QUERY 前，需在 WAF 规则中显式放行并配置对应的检测策略。
Q4：QUERY 和 GET with body 有什么区别？
HTTP/1.1 规范并未禁止 GET 携带请求体，但这一做法被广泛视为反模式，许多代理和服务器会丢弃 GET 请求的 body。QUERY 是被标准明确认可的、携带请求体的只读方法，兼容性远优于 GET with body。
Q5：QUERY 方法的缓存键怎么设计？
RFC 10008 规定，缓存可为 QUERY 结果分配 URI，后续通过 GET 访问。实际缓存键设计需结合请求体内容哈希、Accept-Query 格式等因素，具体实现以各 CDN 和代理厂商文档为准。
Q6：现有的”POST /search”接口要立即迁移到 QUERY 吗？
不建议立即迁移。应等基础设施（服务器、网关、WAF、监控）完整支持后再逐步迁移。迁移期间可保持双方法兼容（同时支持 POST 和 QUERY），平滑过渡。
八、信息来源与免责声明
- 原始标准文档：RFC 10008 – The HTTP QUERY Method（IETF，2026 年 6 月 16 日发布）
- 标准类别：Standards Track / Proposed Standard
- 编写方：IETF HTTP 工作组
- 免责声明：本文所述技术细节基于 RFC 10008 公开文档整理。企业在实际部署 QUERY 方法前，请结合自身基础设施环境（Web 服务器、反向代理、WAF、CDN、API 网关）测试验证，避免因未知方法处理异常导致业务中断。
本文由主机吧安全团队整理，专注为企业站长提供可落地的网络安全实战方案。如需获取 API 安全防护方案与 WAF 规则配置支持，可联系我们。
