Adoção do Método HTTP QUERY

A RFC 10008 foi publicada em junho de 2026. A especificação existe. A pergunta agora é: onde você pode usar QUERY hoje sem que algo quebre no caminho?

A resposta curta: depende de quantos intermediários existem entre seu cliente e seu servidor. O método em si funciona em mais lugares do que a maioria imagina — o problema são os componentes do meio que ninguém atualiza.

“The problem with the internet is that there always will be components that are not going to get updated” — u/good_live, Reddit (130 upvotes)

Esta página documenta o estado real de suporte, sem hype.

---

Tabela de Adoção

Linguagens e Frameworks

Tecnologia	Status	Notas	Como usar
Go (net/http)	✅ Funciona	Go 1.22+ aceita qualquer método em ServeMux e http.NewRequest	mux.HandleFunc("QUERY /rota", handler)
Node.js (core)	✅ Funciona	Suporte nativo adicionado (issue #51562) — llhttp aceita QUERY	http.request({ method: 'QUERY', ... })
Fastify	✅ Via config	Não vem nos métodos padrão; precisa registrar com addHttpMethod	fastify.addHttpMethod('QUERY'); fastify.route({ method: 'QUERY', ... })
Express.js	⚠️ Middleware	Express não bloqueia métodos desconhecidos, mas não tem helper nativo	app.all('/rota', (req, res) => { if (req.method === 'QUERY') ... })
NestJS	⚠️ Workaround	Depende do adaptador HTTP (Express/Fastify). Sem decorator @Query() para rotas	Custom decorator ou middleware
Python (httpx)	✅ Funciona	httpx.request() aceita qualquer string como método	httpx.request('QUERY', url, content=body)
Python (requests)	✅ Funciona	requests.request() aceita método arbitrário	requests.request('QUERY', url, data=body)
Python (Flask)	⚠️ Config	Precisa declarar o método na rota explicitamente	@app.route('/rota', methods=['QUERY'])
Python (Django)	⚠️ Workaround	Views baseadas em classe precisam de dispatch() customizado	Override de dispatch ou middleware
Ruby on Rails	⏳ Proposta aberta	Proposta ativa para adicionar routing helper query	Aguardando merge; hoje funciona via match via: :query
Spring Boot (Java)	⚠️ Workaround	@RequestMapping não tem RequestMethod.QUERY; precisa extensão	@RequestMapping(method = "QUERY") não compila — precisa filtro customizado
ASP.NET Core	⚠️ Workaround	Não há atributo [HttpQuery]; pode usar [AcceptVerbs("QUERY")]	[AcceptVerbs("QUERY")] no controller
PHP (nativo)	✅ Funciona	$_SERVER['REQUEST_METHOD'] reporta qualquer método que o servidor enviar	Funciona se o web server passar o request adiante
Rust (Actix Web)	⚠️ Macro	Precisa usar .route() com guard customizado	web::route().guard(guard::Method(Method::from_str("QUERY")))
Rust (Hyper)	✅ Funciona	http::Method aceita extensões arbitrárias	Method::from_bytes(b"QUERY")

Servidores e Proxies

Tecnologia	Status	Notas	Como usar
Nginx	⚠️ Passa adiante	Nginx repassa métodos desconhecidos para o upstream sem rejeitar, mas não otimiza (sem cache por método). Precisa de módulo extra para caching	proxy_pass funciona. Cache: configure proxy_cache_methods manualmente
Caddy	⚠️ Passa adiante	Similar ao Nginx — repassa sem bloquear, sem suporte explícito a cache por QUERY	reverse_proxy funciona nativamente
Apache httpd	⚠️ Config	mod_proxy repassa, mas Limit/LimitExcept pode bloquear se configurado restritivamente	Remover restrições de LimitExcept se existirem
HAProxy	⚠️ Depende	Versões atuais repassam métodos desconhecidos por padrão. ACLs com method podem filtrar	acl is_query method QUERY funciona para routing
Envoy	⚠️ Passa adiante	Não bloqueia métodos desconhecidos, mas não aplica lógica de safe/idempotent	Funciona como proxy transparente
Traefik	⚠️ Passa adiante	Repassa sem intervenção; sem regras especiais para QUERY	Funciona como proxy transparente

CDNs e Edge

Tecnologia	Status	Notas	Como usar
Cloudflare Workers	✅ Funciona	request.method retorna qualquer método; sem blocklist	if (request.method === 'QUERY') { ... }
Cloudflare CDN (cache)	⏳ Sem cache	CDN não cacheia respostas de métodos não-padrão automaticamente	Workers + Cache API para controle manual
AWS CloudFront	❌ Pode rejeitar	CloudFront tem allowlist de métodos (GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE). QUERY não está na lista	Não suportado sem custom origin com passthrough
AWS ALB	⚠️ Incerto	ALB pode retornar 405 para métodos não reconhecidos dependendo da configuração	Testar; pode precisar de NLB em vez de ALB
Fastly	⚠️ Config VCL	Suporte a método arbitrário via VCL, mas não cacheia por padrão	Custom VCL: if (req.method == "QUERY") { ... }
Vercel Edge	✅ Funciona	Baseado em Workers — aceita qualquer método	request.method === 'QUERY'
Akamai	⏳ Aguardando	Co-autor da RFC (Mark Bishop) é da Akamai. Suporte nativo esperado	Monitorar anúncios

Browsers e Clientes HTTP

Tecnologia	Status	Notas	Como usar
fetch API (todos browsers)	✅ Funciona	fetch() aceita qualquer string em method	fetch(url, { method: 'QUERY', body: ... })
XMLHttpRequest	✅ Funciona	.open() aceita método arbitrário	xhr.open('QUERY', url)
curl	✅ Funciona	-X QUERY funciona. Daniel Stenberg (autor do curl) já discute suporte nativo com -d + QUERY	curl -X QUERY -d '{"filtro":"valor"}' url
HTTPie	✅ Funciona	Aceita método arbitrário	http QUERY url campo=valor
Postman	✅ Funciona	Campo de método aceita texto livre	Digitar “QUERY” no dropdown de método
Insomnia	✅ Funciona	Similar ao Postman	Editar método manualmente

Ferramentas e Infraestrutura

Tecnologia	Status	Notas	Como usar
OpenAPI/Swagger	⏳ Sem suporte	Especificação OpenAPI 3.1 não lista QUERY como operação válida	Aguardando atualização da spec
Terraform (AWS provider)	❌ N/A	Irrelevante — não faz HTTP QUERY	—
gRPC-Web	❌ N/A	Usa POST exclusivamente	—
GraphQL (transporte)	⏳ Possível	Seria o transporte ideal para operações GraphQL query, mas clientes usam POST/GET	Aguardando adoção por clientes GraphQL
Kong Gateway	⚠️ Plugin	Plugins de rate-limit e auth podem não reconhecer QUERY como “safe”	Configurar plugins para aceitar QUERY
API Gateways (genérico)	⚠️ Variável	A maioria bloqueia ou ignora métodos fora da lista padrão	Testar individualmente

---

O Que Pode Dar Errado

QUERY funciona end-to-end quando todos os componentes entre cliente e servidor aceitam o método. Na prática, vários intermediários podem causar problemas:

1. Firewalls e WAFs

Firewalls corporativos e Web Application Firewalls frequentemente mantêm uma allowlist de métodos HTTP. QUERY não está nessa lista. Resultado: 403 Forbidden ou 405 Method Not Allowed silenciosamente.

2. Load Balancers com allowlist

AWS ALB e Classic ELB retornam 405 para métodos fora da lista padrão. Se você usa AWS, considere Network Load Balancer (NLB) que opera na camada 4 e não inspeciona o método HTTP.

3. CDNs que filtram

CloudFront explicitamente lista quais métodos aceita. Se seu CDN não reconhece QUERY, o request nem chega no origin.

4. Proxies corporativos

Em ambientes enterprise, proxies HTTP (Squid, Blue Coat, Zscaler) podem rejeitar métodos desconhecidos. Qualquer coisa entre o browser e seu servidor é um ponto de falha.

5. Frameworks com allowlist

Spring Boot, Django, Rails — frameworks opinados frequentemente têm uma lista fechada de métodos aceitos. Se você não configurar explicitamente, o framework retorna 405 antes de chegar no handler.

6. API Gateways

Kong, AWS API Gateway, Apigee — a maioria valida o método HTTP antes de rotear. Um QUERY não configurado simplesmente desaparece.

7. Monitoramento e Logging

Ferramentas como Datadog, New Relic e Splunk podem categorizar QUERY como “unknown” ou ignorar métricas. Dashboards quebram silenciosamente.

Recomendação prática

Se você controla toda a stack (cliente → servidor, sem intermediários terceiros), pode usar QUERY hoje. Se há qualquer componente que você não controla no meio, teste antes de assumir que funciona.

---

Timeline Realista

A comunidade tem razão em ser cética sobre o tempo de adoção. Vamos olhar o precedente histórico:

Caso de estudo: HTTP PATCH (RFC 5789)

Marco	Data
Primeiro draft publicado	2003
RFC publicada	Março 2010
Suporte em Rails	~2012
Suporte em Django REST Framework	~2013
Suporte em Spring	~2013
Uso generalizado em APIs	~2015–2016
Suporte universal (CDNs, gateways, ferramentas)	~2018–2020

Do RFC ao uso generalizado: ~5–6 anos. Do RFC ao suporte universal: ~8–10 anos.

Projeção para QUERY (RFC 10008)

Fase	Estimativa
RFC publicada	Junho 2026 ✅
Frameworks principais adicionam suporte nativo	2027–2028
CDNs e load balancers reconhecem nativamente	2028–2030
OpenAPI inclui na spec	2027–2028
Uso generalizado em APIs públicas	2030–2032
“Funciona em qualquer lugar sem pensar”	2033–2036

Por que pode ser mais rápido que PATCH

• Autores da RFC são de Cloudflare e Akamai — dois dos maiores CDNs do mundo. Incentivo direto para suporte nativo.
• Node.js já tem suporte antes mesmo da RFC final.
• fetch() nos browsers já funciona — não precisa de atualização de browser.
• GraphQL e APIs complexas criam demanda imediata.

Por que pode ser mais lento que PATCH

• PATCH não precisava de suporte especial em CDNs (não é cacheable por padrão). QUERY precisa — e cache com body é complexo.
• Intermediários legados (Squid, proxies corporativos) não vão atualizar.
• Inércia organizacional: se POST /search funciona, por que mudar?

Veredicto

Espere 3–5 anos para usar QUERY em APIs públicas sem medo. Para APIs internas onde você controla a stack, pode começar hoje.

---

Como Ajudar na Adoção

1. Abra issues nos frameworks que você usa pedindo suporte nativo a QUERY
2. Teste com seu stack e documente o que funciona e o que não funciona
3. Implemente em APIs internas para ganhar experiência real
4. Contribua com PRs para adicionar suporte em projetos open source
5. Reporte bloqueios em CDNs e gateways para os vendors saberem que existe demanda

---

Última atualização: Julho de 2026. Esta página é atualizada periodicamente conforme o ecossistema evolui. Se você encontrou informação desatualizada ou testou alguma tecnologia não listada, abra uma issue ou contribua diretamente.

Legenda: ✅ Funciona nativamente | ⚠️ Funciona com configuração/workaround | ⏳ Suporte esperado/em progresso | ❌ Não funciona / bloqueia