HTTP QUERY: il metodo che mancava tra GET e POST

Dopo oltre quindici anni di compromessi architetturali, l'IETF muove finalmente un passo formale per colmare una delle lacune storiche di HTTP: la gestione sicura ed efficiente delle ricerche complesse.

Con l’introduzione del nuovo metodo HTTP QUERY, infatti, richieste e filtri complessi non dovranno più essere stipati nell'URL né veicolati tramite un metodo non safe come POST.

HTTP QUERY, un nuovo metodo per l’architettura REST

Il metodo HTTP QUERY è il primo standard approvato dall'IETF dai tempi di PATCH, introdotto nell’ormai lontano 2010. Nonostante sia ancora lontano da un’implementazione diffusa, il metodo QUERY promette di risolvere uno dei dilemmi più vecchi dell’architettura REST: come inviare ricerche o filtri complessi senza violare le regole degli standard HTTP.

Fino a oggi, le ricerche avanzate andavano gestite tramite compromessi: né GET né POST, infatti, sono soluzioni ideali.

Il metodo GET prevede che l’invio dei dati avvenga tramite i parametri nella URL (che comunque ha dei limiti di lunghezza). Inserendo i parametri di ricerca nell’URL, però, si rischia di esporre dati sensibili nei log dei server: filtrare un determinato nome e cognome, per esempio, significherà renderlo visibile nei log. Dover usare la URL, inoltre, rende impossibile eseguire query complesse, come ricerche SQL o con filtri avanzati.

POST, d’altro canto, risolve i problemi di spazio inserendo la query nel body, ma non è un metodo sicuro (safe). POST, infatti, è pensato per creare o modificare dati, ovvero per alterare i dati sul server. Si dice, a proposito, che non è un metodo idempotente: inviare la stessa richiesta più volte, usando POST, non produce sempre lo stesso risultato (come avviene per esempio con GET o PUT).

Le caratteristiche del metodo QUERY

Il nuovo metodo HTTP QUERY risolve il problema unendo due caratteristiche fondamentali: la prima è che invia i parametri del body della richiesta senza esporli nell’URL, come POST; la seconda è che si tratta di un metodo idempotente e cacheabile, come GET.

Riassumendo, il metodo QUERY:

• Invia i dati nel body: quindi può contenere JSON, GraphQL, SQL-like syntax, o filtri complessi (senza i limiti di spazio delle query strings) pur mantenendo una URL pulita;
• È safe: garantisce al server e alle CDN che l'operazione è di sola lettura e non modificherà lo stato delle risorse;
• È idempotente: la stessa richiesta restituisce lo stesso risultato, consentendo ai client di eseguire retry automatici in caso di errore di rete;
• È memorizzabile nella cache: proxy, CDN e browser possono memorizzare la risposta generando una chiave di cache basata sulla combinazione di URL e body.

QUERY, dunque, illustrato nell’RFC 10008 pubblicato dall’IETF nel giugno 2026, risolve un’incongruenza con cui gli sviluppatori sono obbligati a confrontarsi da anni, unendo la sicurezza e l’idempotenza di GET con la capacità strutturale di trasportare un payload molto dettagliato nel body della richiesta, come avviene con POST.

Il Content-Type nel metodo QUERY

In base alle specifiche definite dall’RFC 10008, quando in una richiesta QUERY è presente un body, è obbligatorio che vi sia anche il Content-Type. Il body, infatti può contenere formati completamente diversi tra loro, ma il server e le componenti di rete (come proxy e CDN) devono sapere esattamente come interpretarlo prima di elaborarlo o di salvarlo in cache.

Il nuovo standard introduce a tal proposito un header di risposta “Accept-Query”, che dice al client quali formati di query il server è in grado di accettare ed elaborare nel body di una richiesta.

L’RFC 10008 introduce anche i relativi messaggi di errore:

• 400 Bad Request: se il media type è assente o il body è sintatticamente errato;
• 415 Unsupported Media Type: se il formato non è supportato dall’endpoint;
• 406 Not Acceptable: se il formato richiesto in “Accept” non può essere fornito;
• 422 Unprocessable Content: se la query è sintatticamente valida (es. JSON corretto) ma i dati violano le regole di business dell'applicazione e per il server non hanno senso logico.

HTTP QUERY: la strada per l’adozione del nuovo metodo

L’adozione diffusa del metodo QUERY è prevista indicativamente tra il 2027 e il 2028. Prima che il nuovo verbo diventi uno standard concreto nell'operatività quotidiana, bisognerà aspettare che l’intero ecosistema software si adegui: browser, CDN e framework server dovranno aggiornare le proprie librerie per riconoscere e gestire correttamente il nuovo metodo.

E ci sono ancora da risolvere delle potenziali criticità che richiederanno un adeguamento dei sistemi di sicurezza di rete:

• Punti ciechi nei firewall: i firewall per applicazioni web (WAF) tradizionali controllano il corpo del messaggio solo per i metodi che modificano i dati (POST, PUT). Trattando QUERY come un metodo sicuro di sola lettura, rischiano di ignorare il body, lasciando passare attacchi come SQL Injection o XSS;
• Aggiramento dei controlli Anti-CSRF: Poiché QUERY è classificato come metodo "safe", i middleware anti-CSRF lo ignorano per impostazione predefinita. Se uno sviluppatore implementa male l'endpoint facendogli modificare dati sul server, l'applicazione diventa vulnerabile ad attacchi CSRF;
• Preflight: QUERY non rientra tra i metodi base autorizzati automaticamente dai browser (safelisted). Le chiamate da domini diversi richiederanno sempre una richiesta preliminare di controllo (OPTIONS), potenzialmente raddoppiando i tempi di rete.

In ogni caso, la strada per l’implementazione del metodo QUERY è tracciata. D’ora in poi, il protocollo HTTP permetterà di inviare richieste complesse senza modificare le risorse, unendo la flessibilità POST e le garanzie di sola lettura e riproducibilità di GET.