摘要 本规范定义了 HTTP 的 QUERY 方法。QUERY 请求请求目标处理包含的内容，以安全和幂等的方式，然后以结果响应。与 POST 请求类似，但是 QUERY 请求可以自动重复或重新启动，而无需担心部分状态变化。¶ 本备忘录的状态 本文档是互联网标准轨道文件。¶ 本文件是互联网工程任务组（IETF）的成果，代表了 IETF 社区的共识。它已通过公众审查，并获得互联网工程指导组（IESG）的发布批准。有关互联网标准的更多信息，请参见 RFC 7841 第 2 节。¶ 关于本文件当前状态、任何勘误，以及如何提供反馈的信息，可以在 https://www.rfc-editor.org/info/rfc10008 获取。¶ 版权声明 版权 (c) 2026 IETF 基金会和被认定为文件作者的人士。保留所有权利。¶ 本文件受 BCP 78 及 IETF 基金会与 IETF 文档相关的法律条款（ https://trustee.ietf.org/license-info ）的约束，自本文件发布之日起生效。请仔细审查这些文件，因为它们描述了您对本文件的权利和限制。从本文件提取的代码组件必须包含修订过的 BSD 许可证文本，如信任法律条款第 4.e 节所述，并且按照修订过的 BSD 许可证的规定提供，无任何担保。¶ 1. 引言 本规范定义了 HTTP QUERY 请求方法，作为一种发出安全且幂等请求的手段（[HTTP] 第 9.2 节），该请求封装了描述如何处理请求的目标资源的表示。¶ 常见的查询模式是：¶ 然而，当所传递的数据过于庞大而无法编码在请求的 URI 中时，这种模式就变得有问题：¶ 作为使用 GET 的替代方案，许多实现利用 HTTP POST 方法来执行查询，如下面的示例所示。在这种情况下，查询操作的输入作为请求内容传递，而不是使用请求 URI 的查询组件。¶ 使用 HTTP POST 请求查询的典型示例如下：¶ 然而，在这种变体中，不容易显而易见——没有特定的资源和服务器知识——正在执行安全的、幂等的查询。¶ QUERY 方法提供了一种解决方案，填补了 GET 和 POST 之间的空白，上面的示例可以表示为：¶ 与 POST 一样，查询操作的输入作为请求的内容传递，而不是作为请求 URI 的一部分。然而，与 POST 不同，该方法明确是安全和幂等的，允许缓存和自动重试等功能工作。¶ 认识到设计原则，即任何重要资源都应通过 URI 识别，本规范描述了服务器如何为查询本身或特定查询结果分配 URI，以便于将来在 GET 请求中使用。¶ 总结：¶ 表 1：相关方法属性摘要 GET QUERY POST 安全 是 是 潜在 否 幂等 是 是 潜在 否 查询本身的 URI 是（按定义） 可选（位置响应字段） 否 查询结果的 URI 可选（内容位置响应字段） 可选（内容位置响应字段） 可选（内容位置响应字段） 可缓存 是 是 是，但仅用于将来的 GET 或 HEAD 请求 内容（主体） “无定义语义” 预期（针对目标资源的语义） 预期（针对目标资源的语义） 1.2. 符号约定 本文档中的关键字 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 应根据 BCP 14 [RFC2119][RFC8174] 的描述进行解释，且仅在全大写时，如此处所示。¶ 2. QUERY 方法 QUERY 方法用于启动服务器端查询。与 GET 方法（[HTTP] 第 7.1 节）请求由目标 URI 标识的资源表示不同，QUERY 方法用于请求目标资源在该目标资源的范围内执行查询操作。¶ 请求的内容及其媒体类型定义了查询。源服务器根据目标资源确定操作的范围。¶ 如果 Content-Type 请求字段（[HTTP]，第 8.3 节）缺失或与请求内容不一致，服务器必须使请求失败。¶ 与所有 HTTP 方法一样，目标 URI 的查询部分在识别被查询的资源时发挥作用。它是否及如何直接影响查询结果与资源相关，超出本规范的范围。¶ QUERY 请求在目标资源上是安全的