{"id":36301,"date":"2026-07-29T13:35:07","date_gmt":"2026-07-29T11:35:07","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=36301"},"modified":"2026-07-29T13:35:09","modified_gmt":"2026-07-29T11:35:09","slug":"http-query-il-metodo-che-mancava-tra-get-e-post","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/backend-it\/http-query-il-metodo-che-mancava-tra-get-e-post\/","title":{"rendered":"HTTP QUERY: il metodo che mancava tra GET e POST"},"content":{"rendered":"\n

Per quasi trent’anni il Web ha convissuto con un paradosso semantico che chiunque sviluppi per il backend conosce bene: come si esegue un’interrogazione complessa, voluminosa o contenente dati sensibili, se l’unico metodo “sicuro” a disposizione non prevede un corpo della richiesta?<\/p>\n\n\n\n

Pensiamo a quando dobbiamo inviare una query di ricerca strutturata con filtri annidati, ordinamenti e paginazioni multidimensionali. O magari una query SQL, un’espressione JSONPath o un documento GraphQL.<\/p>\n\n\n\n

Il pensiero del programmatore ingenuo \u00e8: aggiungo un parametro “q” all’URI e lo invio con GET, cosa sar\u00e0 mai.<\/p>\n\n\n\n

Poi col tempo i parametri diventano 10, 100, 1000 e il programma implode. Questo succede perch\u00e9 il proxy che attraversa il firewall, memorizza i dati su Redis e fa bilanciamento del carico ha un limite di 2048 caratteri per l’URI. Oppure succede perch\u00e9 il firewall registra in chiaro l’URI e lo invia a un SIEM, esponendo dati sensibili come filtri di ricerca o credenziali.<\/p>\n\n\n\n

Infilare tutto questo in un URI con il classico metodo GET ci espone a limiti fisici di trasporto e a seri rischi di sicurezza.<\/p>\n\n\n\n

Cosa fa invece chi vuole un minimo di sicurezza? Usa solo richieste POST: tutto rimane celato nel corpo della richiesta e non importa se distruggiamo la semantica, impediamo il caching o portiamo ai suicidio il nostro professore di sistemi, l’importante \u00e8 che la sicurezza sia salva.<\/p>\n\n\n\n

Ho lavorato con un progetto alla cui base c’\u00e8 questa logica: rozza, ma efficace.<\/p>\n\n\n\n

L’RFC 10008, pubblicato dall’IETF nel giugno 2026 e classificato come Proposed Standard, risolve finalmente questo dilemma introducendo il metodo QUERY. Proviamo a capire se ne vale la pena o se \u00e8 arrivato troppo tardi sulle nostre scrivanie. Una cosa infatti \u00e8 lo standard, un’altra \u00e8 la sua adozione, per la quale ci vorranno anni. Si tratta di aggiornare linguaggi, framework, librerie, proxy, bilanciatori, CDN, WAF e browser.<\/p>\n\n\n\n

Questo nuovo verbo combina la garanzia semantica di sicurezza e idempotenza (tipiche di GET) con la capacit\u00e0 strutturale di trasportare un payload esteso nel corpo della richiesta (tipica di POST).<\/p>\n\n\n\n

In questo articolo esploreremo la genesi del metodo QUERY, come funziona sotto il cofano, le sue implicazioni su caching e sicurezza, e come possiamo implementarlo oggi nei nostri backend (o almeno in futuro, quando l’ecosistema smetter\u00e0 di rifiutare la richiesta con un desolante HTTP\/1.0 405 Method Not Allowed).<\/p>\n\n\n

QUERY trasporta l'interrogazione nel corpo della richiesta, superando i limiti di GET, ma con una semantica di sicurezza che POST non pu\u00f2 garantire.<\/code><\/span><\/pre>\n\n\n
La genesi di uno standard: AUTH48 e il ruolo dell’IETF<\/h2>\n\n\n\n
Il metodo QUERY non \u00e8 nato dall’oggi al domani. \u00c8 il frutto del lavoro del gruppo HTTPbis dell’IETF, redatto da nomi noti dell’ingegneria dei protocolli come Julian Reschke (greenbytes), James M. Snell (Cloudflare) e Mike Bishop (Akamai).<\/p>\n\n\n\n
Un dettaglio interessante riguarda la fase finale di revisione dello standard, nota come “AUTH48”. Per la prima volta, l’RFC Production Center (RPC) ha utilizzato un progetto pilota basato su repository GitHub anzich\u00e9 sui tradizionali e lenti flussi di email (https:\/\/github.com\/rfc-editor-drafts\/FinalReview-rfc10008).<\/p>\n\n\n\n
Questo ha permesso una tracciabilit\u00e0 granulare delle modifiche redazionali, accelerando il rilascio di uno standard che promette di cambiare le regole del gioco.<\/p>\n\n\n\n
Il problema: i limiti fisici e semantici di GET e POST<\/h2>\n\n\n\n
Per apprezzare il valore di QUERY, dobbiamo guardare da vicino le limitazioni che ci hanno tormentato per decenni.<\/p>\n\n\n\n
I limiti di GET: tra URI troppo lunghi e log in chiaro<\/h2>\n\n\n\n
Con GET la query vive interamente nell’URI. Anche se l’RFC 9110 raccomanda che l’infrastruttura supporti URI di almeno 8000 ottetti, nella realt\u00e0 ci scontriamo con firewall, load balancer e CDN non coordinati che applicano limiti inferiori e variabili. Chi lavora in ambito enterprise sa bene che 2048 caratteri \u00e8 un limite comune, mentre alcuni proxy pi\u00f9 vecchi si fermano a 1024.<\/p>\n\n\n\n
Il superamento di questi limiti genera errori come “414 URI Too Long”, sempre difficili da diagnosticare, soprattutto quando il problema si manifesta solo in ambienti di produzione con traffico reale.<\/p>\n\n\n\n
\"\"<\/figure>\n\n\n\n
C’\u00e8 poi un problema critico di privacy: gli URI vengono registrati in chiaro nei log dei server. Una semplice ricerca tramite grep pu\u00f2 estrarre una grande quantit\u00e0 di dati sensibili con lo sforzo minimo.<\/p>\n\n\n\n
Ricordo ancora quando, durante una delle mie prime analisi di sicurezza dei log per un grande operatore nazionale di telecomunicazioni, saltai letteralmente sulla sedia: guardandoli, mi resi conto che tutte le login di un certo applicativo avvenivano in GET anzich\u00e9 in POST. Le password di migliaia di utenti erano l\u00ec, scritte in chiaro nei file di testo del server web.<\/p>\n\n\n\n
Oltre a questo, anche se il fenomeno \u00e8 molto pi\u00f9 mitigato rispetto al passato, gli header “Referer” verso siti terzi possono trasportare dati che dovevano rimanere segregati nel server di origine.<\/p>\n\n\n\n
Per questi motivi GET ha un peccato originale: non \u00e8 adatto a trasportare dati sensibili, eppure \u00e8 l’unico metodo sicuro e idempotente disponibile.<\/p>\n\n\n\n
Infine, memorizzare in cache queste richieste \u00e8 inefficiente. Qualsiasi variazione sintattica nell’ordine dei parametri o nella codifica dei caratteri invalida la cache, trasformando query semanticamente identiche in risorse distinte.<\/p>\n\n\n\n
Il ripiego su POST: la perdita del contratto semantico<\/h2>\n\n\n\n
Per aggirare i limiti di GET, la prassi comune \u00e8 stata quella di abusare di POST, spostando la query nel body: un approccio semplice, ma con conseguenze semantiche significative.<\/p>\n\n\n\n
In questo modo non abbiamo pi\u00f9 problemi di spazio nell’URI e i log rimangono puliti (\u00e8 vero che si pu\u00f2 abilitare il logging del body, ma di default non \u00e8 attivo), ma il meccanismo rompe le garanzie del protocollo. Il metodo POST non \u00e8 n\u00e9 sicuro n\u00e9 idempotente per definizione.<\/p>\n\n\n\n
Di conseguenza, gli intermediari coinvolti nel trasporto di una richiesta POST, non sapendo se stia leggendo dati o modificando un database, evitano di reinviare i dati (come avviene con i browser) o di effettuare il caching (come avviene con le CDN).<\/p>\n\n\n\n
I precursori WebDAV e perch\u00e9 evitare SEARCH o REPORT<\/h2>\n\n\n\n
Chi ha pi\u00f9 esperienza o qualche capello grigio ricorder\u00e0 sicuramente i tentativi fatti con WebDAV e metodi come “SEARCH” o “PROPFIND”. C’\u00e8 ancora chi pensa che WebDAV sia una soluzione perfetta, ma forse dovrebbe ricredersi dopo questa specifica e su come abbia volutamente ignorato i metodi WebDAV per crearne uno completamente nuovo.<\/p>\n\n\n\n
Si \u00e8 deciso per\u00f2 di non riciclare quei metodi, che nascevano legati a doppio filo con il Content-Type “application\/xml”, ma di ripartire da zero.<\/p>\n\n\n\n
QUERY nasce cos\u00ec agnostico, non legato a un formato specifico, in modo che chi lo utilizza possa gestire in autonomia il proprio “Content-Type”.<\/p>\n\n\n\n
Stiamo quindi prendendo le cose positive di GET: sicurezza, idempotenza e caching, e vi si aggiunge il corpo della richiesta POST.<\/p>\n\n\n\n
Negoziazione del contenuto e codici di errore<\/h2>\n\n\n\n
Ragionando con il “Content-Type” iniziano ad arrivare i primi vincoli: se un client chiede un formato “application\/xml” e il server ha un contenuto diverso, la richiesta viene rigettata. Lo stesso avviene se il client non indica in modo esplicito questo dato.<\/p>\n\n\n\n
Lo standard definisce in modo rigoroso questo passaggio all’interno della sezione “2.1 Media Types and Content Negotiation”:<\/p>\n\n\n\n