Timeline — Do SEARCH ao QUERY
De um individual draft em abril de 2015 até a publicação como RFC 10008 em junho de 2026. A jornada completa do método que o HTTP precisava.
Cronologia
Seção intitulada “Cronologia”2015 — A semente
Seção intitulada “2015 — A semente”| Data | Marco |
|---|---|
| Abr 2015 | draft-snell-search-method-00 — James Snell propõe redefinir o método SEARCH do WebDAV como um método HTTP genérico, safe e idempotent. |
James Snell identificou o problema: GET não aceita body, POST não é safe. A solução inicial foi reutilizar o SEARCH já registrado na IANA via RFC 5323 (WebDAV), redefinindo sua semântica para uso geral.
2018–2020 — Pausa e retomada
Seção intitulada “2018–2020 — Pausa e retomada”| Data | Marco |
|---|---|
| Set 2018 | draft-snell-search-method-01 — Revisão individual. Ajustes editoriais, mesma ideia. |
| Set 2020 | draft-snell-search-method-02 — Terceira revisão. Maturidade suficiente para adoção no working group. |
Três anos entre a primeira e a segunda revisão. O draft ficou hibernando enquanto a comunidade HTTP discutia se o problema merecia um método novo ou se bastava usar POST com headers adicionais.
2021 — Adoção pelo httpbis e a mudança de nome
Seção intitulada “2021 — Adoção pelo httpbis e a mudança de nome”| Data | Marco |
|---|---|
| Mar 2021 | draft-ietf-httpbis-safe-method-w-body-00 — O httpbis WG adota o draft. Ainda chamado SEARCH. |
| Jun 2021 | draft-ietf-httpbis-safe-method-w-body-01 — Discussões sobre conflito com WebDAV SEARCH se intensificam. |
| Nov 2021 | draft-ietf-httpbis-safe-method-w-body-02 — SEARCH é renomeado para QUERY. Marco decisivo. |
O momento mais controverso do processo. O problema: o método SEARCH já existia no registro IANA (RFC 5323, WebDAV). Reutilizá-lo com semântica diferente quebraria clientes WebDAV existentes. A solução: nome novo — QUERY. Simples, descritivo, sem bagagem histórica.
2022–2024 — Refinamento lento
Seção intitulada “2022–2024 — Refinamento lento”| Data | Marco |
|---|---|
| Jul 2022 | draft-ietf-httpbis-safe-method-w-body-03 — Oito meses de silêncio, depois ajustes na semântica de caching. |
| Set 2024 | draft-ietf-httpbis-safe-method-w-body-04 — Dois anos entre draft 03 e 04. Retomada do trabalho ativo. |
| Set 2024 | draft-ietf-httpbis-safe-method-w-body-05 — Mesmo mês. Ajustes rápidos em sequência. |
| Out 2024 | draft-ietf-httpbis-safe-method-w-body-06 — Alinhamento com HTTP Semantics (RFC 9110). |
| Dez 2024 | draft-ietf-httpbis-safe-method-w-body-07 — Questões de segurança e content negotiation refinadas. |
O gap de dois anos (jul/2022 → set/2024) é típico do processo IETF: o working group tinha outros deliverables prioritários (HTTP/3, Resumable Uploads, etc.).
2025 — Sprint final
Seção intitulada “2025 — Sprint final”| Data | Marco |
|---|---|
| Fev 2025 | draft-ietf-httpbis-safe-method-w-body-08 — Respostas ao IETF Last Call. |
| Abr 2025 | draft-ietf-httpbis-safe-method-w-body-09 — Ajustes pós-IESG review. |
| Abr 2025 | draft-ietf-httpbis-safe-method-w-body-10 — Incorpora feedback de área directors. |
| Mai 2025 | draft-ietf-httpbis-safe-method-w-body-11 — Últimos ajustes editoriais antes de AUTH48. |
| Set 2025 | draft-ietf-httpbis-safe-method-w-body-12 — Revisão AUTH48 em andamento. |
| Nov 2025 | draft-ietf-httpbis-safe-method-w-body-13 — Correções finais do RFC Editor. |
| Nov 2025 | draft-ietf-httpbis-safe-method-w-body-14 — Versão final antes da publicação. |
Sete drafts em oito meses. Depois de anos de progresso lento, a reta final foi acelerada.
2026 — Publicação
Seção intitulada “2026 — Publicação”| Data | Marco |
|---|---|
| 15 Jun 2026 | RFC 10008 — Publicada como Proposed Standard. Autores: Julian Reschke (greenbytes), James Snell (Cloudflare), Mike Bishop (Akamai). |
Onze anos, três meses. De individual draft a RFC.
Por que demorou tanto?
Seção intitulada “Por que demorou tanto?”1. Consenso IETF não é votação
Seção intitulada “1. Consenso IETF não é votação”O IETF funciona por rough consensus. Não basta maioria — é preciso resolver objeções técnicas válidas. Cada concern de implementadores, proxy vendors e security reviewers precisava ser endereçada. Isso leva tempo, mas produz specs robustas.
2. O conflito com WebDAV SEARCH
Seção intitulada “2. O conflito com WebDAV SEARCH”O nome SEARCH já estava registrado na IANA desde 2008 (RFC 5323). O draft original tentava “reciclar” esse método, redefinindo sua semântica. Isso gerou resistência:
- Clientes WebDAV existentes esperavam o comportamento antigo
- Proxies intermediários poderiam se confundir com a semântica dupla
- A IANA registration exigia clareza sobre backward compatibility
A solução (renomear para QUERY em novembro de 2021) resolveu o impasse, mas custou meses de debate.
3. Prioridades concorrentes
Seção intitulada “3. Prioridades concorrentes”O httpbis WG é o mesmo grupo que entregou:
- HTTP/2 (RFC 9113)
- HTTP/3 (RFC 9114)
- HTTP Semantics (RFC 9110)
- Resumable Uploads
- Structured Fields
QUERY competia por atenção e review time com essas specs maiores. O gap de 2 anos (2022–2024) reflete isso.
4. O problema é sutil
Seção intitulada “4. O problema é sutil”“GET com body” parece simples. Mas as implicações para caching, intermediários, content negotiation e segurança são não-triviais. A spec precisava definir:
- Como caches fazem key do conteúdo (variando no body)
- Interação com Content-Encoding e Transfer-Encoding
- Quando e como intermediários podem transformar a request
- Se o body é obrigatório ou opcional
O que vem depois
Seção intitulada “O que vem depois”RFC 10008 foi publicada como Proposed Standard. No processo de standards da IETF (RFC 2026), existem três níveis:
| Nível | Requisito | Status atual |
|---|---|---|
| Proposed Standard | Spec estável, review da comunidade completo | ✅ Onde estamos (Jun 2026) |
| Draft Standard | Pelo menos duas implementações independentes e interoperáveis | Próximo passo |
| Internet Standard | Experiência operacional significativa, adoção ampla | Futuro |
Na prática, a maioria das specs HTTP modernas (incluindo HTTP/2 e HTTP/3) opera como Proposed Standard por anos. A promoção a Internet Standard é mais burocrática que técnica — confirma que o mercado já adotou.
O que importa agora:
- Implementação em servidores: Node.js, Go, Python frameworks adicionando suporte
- Suporte em proxies: CDNs e load balancers precisam entender o método
- Adoção em APIs: GraphQL, Elasticsearch e REST APIs migrando de POST para QUERY