Timeline — From SEARCH to QUERY
From an individual draft in April 2015 to publication as RFC 10008 in June 2026. The complete journey of the HTTP method we needed.
Chronology
Section titled “Chronology”2015 — The seed
Section titled “2015 — The seed”| Date | Milestone |
|---|---|
| Apr 2015 | draft-snell-search-method-00 — James Snell proposes redefining the WebDAV SEARCH method as a generic, safe, idempotent HTTP method. |
James Snell identified the problem: GET doesn’t accept a body, POST isn’t safe. The initial approach was to reuse SEARCH — already registered at IANA via RFC 5323 (WebDAV) — by redefining its semantics for general use.
2018–2020 — Pause and revival
Section titled “2018–2020 — Pause and revival”| Date | Milestone |
|---|---|
| Sep 2018 | draft-snell-search-method-01 — Individual revision. Editorial fixes, same core idea. |
| Sep 2020 | draft-snell-search-method-02 — Third revision. Mature enough for working group adoption. |
Three years between the first and second revisions. The draft hibernated while the HTTP community debated whether the problem warranted a new method or could be solved with POST plus additional headers.
2021 — Working group adoption and the rename
Section titled “2021 — Working group adoption and the rename”| Date | Milestone |
|---|---|
| Mar 2021 | draft-ietf-httpbis-safe-method-w-body-00 — The httpbis WG adopts the draft. Still called SEARCH. |
| Jun 2021 | draft-ietf-httpbis-safe-method-w-body-01 — Debate over WebDAV SEARCH conflict intensifies. |
| Nov 2021 | draft-ietf-httpbis-safe-method-w-body-02 — SEARCH is renamed to QUERY. Decisive moment. |
The most contentious phase. The problem: the SEARCH method already existed in the IANA registry (RFC 5323, WebDAV). Reusing it with different semantics would break existing WebDAV clients. The solution: a fresh name — QUERY. Simple, descriptive, no historical baggage.
2022–2024 — Slow refinement
Section titled “2022–2024 — Slow refinement”| Date | Milestone |
|---|---|
| Jul 2022 | draft-ietf-httpbis-safe-method-w-body-03 — Eight months of silence, then caching semantics adjustments. |
| Sep 2024 | draft-ietf-httpbis-safe-method-w-body-04 — Two years between draft 03 and 04. Active work resumes. |
| Sep 2024 | draft-ietf-httpbis-safe-method-w-body-05 — Same month. Rapid sequential fixes. |
| Oct 2024 | draft-ietf-httpbis-safe-method-w-body-06 — Alignment with HTTP Semantics (RFC 9110). |
| Dec 2024 | draft-ietf-httpbis-safe-method-w-body-07 — Security and content negotiation details refined. |
The two-year gap (Jul 2022 → Sep 2024) is typical of IETF process: the working group had higher-priority deliverables (HTTP/3, Resumable Uploads, etc.).
2025 — Final sprint
Section titled “2025 — Final sprint”| Date | Milestone |
|---|---|
| Feb 2025 | draft-ietf-httpbis-safe-method-w-body-08 — Responds to IETF Last Call feedback. |
| Apr 2025 | draft-ietf-httpbis-safe-method-w-body-09 — Post-IESG review adjustments. |
| Apr 2025 | draft-ietf-httpbis-safe-method-w-body-10 — Incorporates area director feedback. |
| May 2025 | draft-ietf-httpbis-safe-method-w-body-11 — Final editorial adjustments before AUTH48. |
| Sep 2025 | draft-ietf-httpbis-safe-method-w-body-12 — AUTH48 review in progress. |
| Nov 2025 | draft-ietf-httpbis-safe-method-w-body-13 — Final RFC Editor corrections. |
| Nov 2025 | draft-ietf-httpbis-safe-method-w-body-14 — Final version before publication. |
Seven drafts in eight months. After years of slow progress, the finish line came fast.
2026 — Publication
Section titled “2026 — Publication”| Date | Milestone |
|---|---|
| Jun 15, 2026 | RFC 10008 — Published as a Proposed Standard. Authors: Julian Reschke (greenbytes), James Snell (Cloudflare), Mike Bishop (Akamai). |
Eleven years, three months. From individual draft to RFC.
Why did it take so long?
Section titled “Why did it take so long?”1. IETF consensus isn’t a vote
Section titled “1. IETF consensus isn’t a vote”The IETF operates by rough consensus. Majority isn’t enough — you must resolve valid technical objections. Every concern from implementers, proxy vendors, and security reviewers had to be addressed. This takes time, but produces robust specs.
2. The WebDAV SEARCH conflict
Section titled “2. The WebDAV SEARCH conflict”The SEARCH name was already registered at IANA since 2008 (RFC 5323). The original draft tried to “recycle” this method by redefining its semantics. This met resistance:
- Existing WebDAV clients expected the old behavior
- Intermediary proxies might be confused by dual semantics
- IANA registration required clarity on backward compatibility
The fix (renaming to QUERY in November 2021) resolved the deadlock, but cost months of debate.
3. Competing priorities
Section titled “3. Competing priorities”The httpbis WG is the same group that delivered:
- HTTP/2 (RFC 9113)
- HTTP/3 (RFC 9114)
- HTTP Semantics (RFC 9110)
- Resumable Uploads
- Structured Fields
QUERY competed for attention and review time with these larger specs. The 2-year gap (2022–2024) reflects that reality.
4. The problem is subtle
Section titled “4. The problem is subtle”“GET with a body” sounds simple. But the implications for caching, intermediaries, content negotiation, and security are non-trivial. The spec needed to define:
- How caches key on content (varying on the body)
- Interaction with Content-Encoding and Transfer-Encoding
- When and how intermediaries can transform the request
- Whether the body is mandatory or optional
What comes next
Section titled “What comes next”RFC 10008 was published as a Proposed Standard. In the IETF standards process (RFC 2026), there are three levels:
| Level | Requirement | Current status |
|---|---|---|
| Proposed Standard | Stable spec, community review complete | ✅ Where we are (Jun 2026) |
| Draft Standard | At least two independent, interoperable implementations | Next step |
| Internet Standard | Significant operational experience, wide adoption | Future |
In practice, most modern HTTP specs (including HTTP/2 and HTTP/3) operate as Proposed Standards for years. Promotion to Internet Standard is more bureaucratic than technical — it confirms that the market has already adopted it.
What matters now:
- Server implementations: Node.js, Go, Python frameworks adding support
- Proxy support: CDNs and load balancers need to understand the method
- API adoption: GraphQL, Elasticsearch, and REST APIs migrating from POST to QUERY