🇧🇷 Leia esta análise em português
If you have written an API in the last fifteen years, you already know the problem QUERY was invented to solve. You needed to send a read request with a filter too complex to fit in a URL, so you did what everyone does: you sent a POST /search and pretended it was a read. It worked. It also quietly threw away every guarantee the protocol gives you about safe, idempotent, cacheable requests.
🇬🇧 Read this analysis in English
Se você escreve APIs há quinze anos, já conhece o problema que o QUERY foi inventado para resolver. Em algum momento você precisou enviar uma requisição de leitura com um filtro complexo demais para caber em uma URL, e fez o que todo mundo faz: mandou um POST /search e fingiu que era uma leitura. Funcionou. Também jogou fora, silenciosamente, todas as garantias que o protocolo dá sobre requisições seguras (safe), idempotentes e cacheáveis.
AAAAA isso vai ser insano Tenho minhas suspeitas que ele vai trazer algumas headers que não são usadas geralmente por nenhum parser de HTTP (até mesmo 100% ignoradas por alguns parsers)
/* MAS SAO INTERPRETADAS PELO PROXIMO SERVIDOR EM CURSO A RECEBÊ-LA*/ e que essa inconsistência pode gerar requests smuggling por padrão.
Que esse desync pode causar DOS e muitas vezes leaking de dados de requisições de outros usuários
Essas vulnerabilidades a nível de integrações / entre servidores, na minha visão são umas das mais chatas de corrigir (e por consequência uma das mais negligenciadas e sucetíveis a vulnerabilidades).