IETF发布QUERY方法，为HTTP请求提供安全幂等新选择

当HTTP请求过长或过于复杂，无法通过GET方法编码在URI中时，开发者长期以来一直将POST方法作为替代方案。然而，这种做法存在一定问题：GET请求被定义为安全且幂等的，但POST方法并不一定具备这些特性。

为解决这一问题，互联网工程任务组（IETF）发布了一项HTTP请求方法提案标准——QUERY（RFC 10008），该方法融合了GET与POST各自的优势。

所谓"安全"方法，是指本质上为只读操作，即客户端在对目标资源应用安全方法时，不会请求也不期望服务器端发生任何状态变更。IETF标准文件同时指出，合理使用安全方法不应对源服务器造成任何损害、财产损失或异常负担。而"幂等"则意味着，无论请求被重试多少次，该方法对服务器产生的预期效果与单次请求完全相同。

POST请求并不总能满足上述标准，而QUERY请求则完全符合。与POST类似，QUERY操作的输入内容通过请求体传递，而非像GET那样附加在请求URI中。与POST不同的是，QUERY支持缓存和自动重试等功能，正是因为它本身是安全且幂等的。

Greyhound Research首席分析师Sanchit Vir Gogia表示："RFC 10008的意义在于，它赋予了网络开发中最常见的变通方案一个正式的协议身份。过去二十年里，开发者一直将只读查询伪装成POST命令；QUERY将查询内容放在请求体中，同时声明其可安全重试和缓存。其重要性在于机器可读的语义——重试引擎、缓存系统和自动化智能体依据方法声明来执行操作，而非依赖文档说明。在自动化场景下，语义即策略。"

Gogia进一步解释道："当请求内容能够方便地放入URI时，GET运行良好；但一旦开发者需要处理深层过滤器、大量标识符或完整的查询文档时，GET便力不从心。此外，URI还面临浏览历史、书签和访问日志带来的信息暴露问题，将每种输入组合编码进地址，会悄然将每种排列变成独立的资源。"

"POST解决了长度问题，却没有兑现应有的承诺，"Gogia说道，"其通用语义涵盖创建、修改和副作用等操作，因此任何缓存、重试引擎或网关都无法假定某个POST请求是可重复或可复用的。"

不过，QUERY虽然解决了长期以来用POST处理查询的问题，但新方法也存在一些注意事项。软件工程师Rickvian Aldi在一篇博客文章中指出："谨慎地说：QUERY解决了语义问题，但并非所有部署工作都迎刃而解。前端代码仍需要稳定的查询键，服务器仍需进行验证并设置缓存控制头，基础设施也需要支持这一新方法。"

这一切都需要时间，标准的采纳往往进展缓慢。而在QUERY得到广泛应用之前，HTML表单标准等其他相关标准也需要更新。这项工作已由Web超文本应用技术工作组等机构着手推进。

开源开发者Daniele Teti在博客中写道："以提案标准形式发布RFC，并不意味着整个生态系统第二天就能支持它。这只是IETF标准轨道的第一步：规范已稳定并准备好供实施，但浏览器、服务器、代理、CDN和客户端库真正落地采纳还需要时间。"目前，尚无主流浏览器支持QUERY方法，不过在服务器端，Node.js和Go已支持该方法。

Gogia指出，RFC 10008的作者——来自Cloudflare、Akamai和greenbytes的工程师们——对此有充分认识。

"退路已被设计进标准本身，"Gogia说，"Location桥接机制的存在，使得QUERY在遭遇不支持该方法的基础设施时，能够回退为GET请求。文档也明确指出，客户端可以切换到GET来简化后续请求的处理。从这个角度来看，等效资源机制与其说是一种哲学上的让步，不如说是一个应急预案，而这也正是最有可能帮助该方法度过尴尬过渡期的核心特性。"

Q&A

Q1：QUERY方法和GET、POST方法有什么区别？

A：QUERY方法结合了GET和POST的优点。GET方法将请求内容编码在URI中，存在长度限制和信息暴露问题；POST方法虽能传递大量内容，但不具备安全性和幂等性，无法被缓存或自动重试。QUERY方法将请求内容放在请求体中传递（类似POST），同时声明为安全且幂等的操作（类似GET），因此支持缓存和自动重试功能，适合复杂查询场景。

Q2：RFC 10008发布后，QUERY方法可以立即使用吗？

A：目前还不能广泛使用。以提案标准形式发布RFC只是IETF标准轨道的第一步，实际落地需要浏览器、服务器、代理、CDN和客户端库的全面支持。目前主流浏览器尚未支持QUERY方法，服务器端仅Node.js和Go提供支持。此外，HTML表单标准等相关规范也需要同步更新，整个生态系统的适配还需要较长时间。

Q3：QUERY方法在遇到不支持它的旧基础设施时怎么办？

A：RFC 10008标准本身已内置了兼容性退路机制。通过Location桥接机制，当QUERY请求遭遇不支持该方法的旧基础设施时，可以回退为GET请求。标准文档明确指出，客户端可以切换到GET来简化后续请求的处理。这一应急预案被认为是帮助QUERY方法顺利度过早期推广阶段的关键特性。