Il nuovo metodo HTTP QUERY per query complesse: approfondimento

Il metodo HTTP QUERY è una nuova soluzione per le query complesse. Offre una soluzione sicura e idempotente per le richieste HTTP, risolvendo i problemi dei metodi GET e POST.

Prima di trattare l’argomento nello specifico, partiamo dalla RFC10008, documento prodotto dalla Internet Engineering Task Force (IETF). Con questa specifica si definisce il metodo HTTP QUERY request, utilizzato per effettuare richieste sicure e idempotenti.

Sicurezza e idempotenza sono due concetti fondamentali dei metodi sfruttati nelle richieste HTTP. In questo contesto, per sicurezza di un metodo HTTP intendiamo la caratteristica di quel metodo di non alterare lo stato del server target, mentre per idempotente la caratteristica di effettuare la stessa richiesta più volte, produce lo stesso risultato.

Partendo da questi concetti, la richiesta HTTP deve racchiudere al suo interno una rappresentazione in cui viene descritta come questa viene elaborata dalla risorsa target.

Di base un modello comune di query che sfrutta il metodo GET presenta la seguente forma:

GET /feed?q=foo&limit=10&sort=-published HTTP/1.1
Host: example.org

Tuttavia, queste richieste diventano problematiche quando i dati trasmessi sono molto voluminosi. Citando letteralmente il documento molto spesso i limiti delle dimensioni non sono noti in anticipo perché una richiesta può passare attraverso molte richieste non coordinate; esprimere certi tipi di dati nell’URI di destinazione risulta inefficiente a causa del sovraccarico necessario per codificare quei dati in un URI valido. Inoltre, le URI delle richieste hanno più probabilità di essere registrate rispetto al contenuto e possono anche comparire nei segnalibri. Di conseguenza, codificare le query direttamente nell’URI della richiesta equivale, di fatto, a rendere ogni possibile combinazione di input della query una risorsa distinta.

Come alternativa all’uso del metodo GET, molte implementazioni oggi fanno uso del metodo HTTP POST. In questo caso, l’input all’operazione viene passato come contenuto della richiesta:

POST /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published

Tuttavia, anche questo metodo senza una conoscenza specifica della risorsa e del server a cui viene inviata non permette di avere la sicurezza di una query idempotente.

Il divario fin qui descritto tra l’uso dei metodi GET e POST, viene colmato dal metodo QUERY:

QUERY /feed HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
q=foo&limit=10&sort=-published

Come per POST, l’input dell’operazione di query viene passato come contenuto della richiesta piuttosto che come parte dell’URI. Differentemente dal metodo POST, permette tuttavia l’esecuzione di funzioni come la cache e i tentativi automatici. Di base, riconoscendo il principio di progettazione che qualsiasi risorsa dovrebbe essere identificata da un URI, un server può assegnare un URI alla query stessa o verso un risultato specifico della medesima.

Scendendo nei dettagli quando il metodo QUERY viene utilizzato per avviare una query lato server, la risorsa di destinazione deve eseguire al suo interno un’operazione di richiesta. Il server di origine determina l’ambito dell’operazione in base alla risorsa target e al contenuto della richiesta, mentre il tipo di media definisce la query. Ovviamente le richieste sono sicure verso le risorse target, non provocando nessuna modifica allo stato della risorsa. Questo, tuttavia, non impedisce al server di creare risorse aggiuntive mediante le quali ulteriori informazioni e risorse possono essere recuperate. Inoltre, il fatto che le richieste QUERY sono idempotenti; possono essere riprovate o ripetute quando necessarie, ad esempio dopo un guasto alla connessione, e la risposta a tale metodo risulta anche cacheabile, cosicché una cache può riutilizzarla per soddisfare query successive a patto che la chiave di cache incorpori il contenuto della richiesta e tenga conto della correlazione dei metadati.

Con il metodo QUERY le “Accept-Query” possono contenere un elenco di intervalli di media utilizzando una sintassi strutturata. Ogni intervallo di media è rappresentato con un campo header, tale campo include Token o Stringhe. I parametri relativi al tipo di supporto, se presenti, sono mappati con tipo String oppure Token. La distinzione tra Token e String è semanticamente irrilevante, i destinatari possono convertire i Token in String, ma non devono trattarli in modo diverso in funzione del tipo ricevuto. I tipi di media non si mappano necessariamente in modo esatto ai Token. Ad esempio, quando è necessario “consentire una cifra iniziale” viene richiesto l’uso del formato Stringa, non del Token. Per quanto riguarda le wild card, sono supportati soltanto i seguenti usi:

“/”, che corrisponde a qualsiasi tipo;
“xxxx/*”, che corrisponde a qualsiasi sottotipo del tipo indicato.

L’ordine dei tipi elencati nel valore del campo “Accept-Query” non è significativo. Il valore dell’intestazione si applica a ogni URI sul server che condivide lo stesso percorso. In altre parole, la componente query dell’URI viene ignorata.

Accept-Query: “application/jsonpath”, application/sql;charset=”UTF-8”

Precisiamo in conclusione che il metodo QUERY è soggetto alla stessa sicurezza generale di tutti i metodi http. Un modo semplice per trovare il supporto per il metodo viene fornito dalle OPTIONS che indicano l’insieme dei metodi supportati sulla risorsa specificata:

OPTIONS /contacts HTTP/1.1
Host: example.org
Risposta:
HTTP/1.1 200 OK
Allow: GET, QUERY, OPTIONS, HEAD

Come già specificato nell’articolo scritto da Luigi Zullo “Arriva QUERY: il nuovo metodo HTTP per query complesse” l’adozione del nuovo metodo richiederà del tempo. Le forme HTML attuali supportano solo 8 metodi GET e POST, mentre proxy, load balancer e CDN potrebbero bloccare richieste sconosciute. Gli sviluppatori prevedono che prima saranno i backend e gli strumenti di sviluppo ad adeguarsi, seguiti da piattaforme web e infine dai browser.

Antonino Battaglia

Antonino Battaglia Ingegnere elettronico con oltre dieci anni di esperienza nell'automazione industriale e nella sicurezza informatica. Appassionato di tecnologia blockchain e criptovalute, collabora con Red Hot Cyber, condividendo la sua conoscenza su sicurezza informatica, automazione e IoT.