HTTP: i nuovi status code

Questo articolo intende descrivere le caratteristiche e l'utilizzo dei nuovi Status Codes per il protocollo HTTP, proposti dalla Internet Engineering task Force (IETF) in un draft del 18 ottobre 2011, in aggiunta a quelli già indicati all'interno della RFC2616, che definisce il protocollo HTTP stesso.

Come è noto, l'HTTP è un protocollo a livello applicativo (livello 7 della pila ISO/OSI), disegnato per lo scambio di informazioni nella forma di ipertesti.

HTTP Request e Response

Anzitutto è opportuno ricordare che il meccanismo di funzionamento standard dell'HTTP si basa su richieste formulate dai client e risposte fornite dai server, chiamate per l'appunto HTTP Request e HTTP Response. I messaggi scambiati tra server e client seguono lo standard definito dalla RFC822. Schematizzando:

HTTP-message   = Request | Response     ; HTTP/1.1 messages

Un messaggio di HTTP Request (da un client ad un server) include, alla prima riga del messaggio stesso, una Request-Line nella seguente forma:

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

dove Method indica il metodo (ad es. GET o POST, ma ce ne sono altri) da applicare ad una risorsa identificata dalla c.d. "Request-URI" (Uniform Resource Identifier). SP e CLRF indicano rispettivamente uno spazio e un "Invio". Un classico esempio di Request-Line è dato dal metodo GET applicato ad una qualsiasi URI:

GET http://sicurezza.html.it HTTP/1.1

Più in generale, una chiamata HTTP Request è nella forma:

Request       = Request-Line
                *(( general-header
                 | request-header
                 | entity-header ) CRLF)
                 CRLF
                 [ message-body ]

Dopo aver ricevuto ed interpretato un messaggio di richiesta, il server risponde - come già detto - con un messaggio di HTTP Response che, in analogia alla Request, è nella forma:

Response      = Status-Line
                *(( general-header
                 | response-header
                 | entity-header ) CRLF)
                 CRLF
                 [ message-body ]

Come si vede osservando la struttura del messaggio, la prima riga è costituita dalla Status-Line, che a sua volta è nella forma:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

Gli status code

Lo Status-Code, indicato all'interno della Status-Line, è un numero intero a tre cifre che il server fornisce in risposta ad una richiesta da parte di un client. Subito dopo troviamo inoltre la Reason-Phrase, il cui scopo è quello di fonrire una breve descrizione testuale del dello Status-Code.

Gli Status Codes sono suddivisi in cinque classi, identificate dal primo numero dello Status-Code:

All'interno di ogni classe, è definito un valore per ogni Status-Code, a seconda del tipo di informazione che il server intende fornire al client. Tipici esempi sono:

200 OK

In questo caso lo Status-Code (200) indica che la richiesta ha avuto successo, in relazione al metodo invocato (ad es. una GET). Un altro Status-Code molto comune è, ad esempio, il seguente:

404 Not Found

Questo Status-Code viene fornito come risposta da un server che non ha trovato la risorsa specificata nella Request-URI. Oppure ancora:

403 Forbidden

In questo caso il server ha interpretato la richiesta, ma si rifiuta di esaudirla in quanto evidentemente la risorsa richiesta non deve essere resa disponibile al client.

I nuovi Status-Code

Andiamo ora ad analizzare i nuovi Status Codes proposti:

428 Precondition Required

Questo Status Code è stato formulato per risolvere il problema dell'accesso concorrente di più client ad una stessa risorsa, che ne modificano lo stato.

Accade spesso che un client ottiene una risorsa (ad es. attraverso una GET), ne modifica lo stato, e la rimanda al server (tramite un metodo PUT). Ma se nel frattempo un altro client ne ha già modificato lo stato, ciò conduce ad un conflitto e al cosiddetto problema del "lost update".

Quando il server invia una risposta con questo codice, deve quindi indicare anche COME effettuare nuovamente il SUBMIT, questa volta con successo. Ecco un esempio:

Figura 1. Lo Status Code 429 Precondition Required

429 Too Many Requests

Questo Status Code indica che l'utente ha inviato troppe richieste in un certo intervallo di tempo.
Nella risposta il server deve includere un messaggio che spieghi la condizione verificatasi e può contenere un header di tipo Retry-After che indichi il tempo di attesa fissato prima di inviare una nuova richiesta.

Figura 2. 429 Too Many Requests

L'esempio in figura mostra un tempo di attesa, specificato nel Retry-After, fissato a 3600 secondi. Si noti che il server può stabilire il limite di richieste sia sulla base della disponibilità di risorse, sia sulla base dell'autenticazione dell'utente o di un cookie di tipo "stateful".

431 Request Header Fields Too Large

Questa risposta viene fornita quando il server riceve una HTTP Request avente headers troppo grandi e può verificarsi sia quando gli headers, in totale, sono troppo grandi sia quando un solo header eccede le dimensioni consentite.

Figura 3. 431 Request Header Fields Too Large

L'esempio in figura mostra un messaggio relativo ad un certo header denominato "Example".

511 Network Authentication Required

Per quanto riguarda questo Status Code, il discorso è un pochino più articolato. Siamo nella condizione in cui un utente richiede l'accesso ad una risorsa protetta da un meccanismo di autenticazione, ad esempio tramite un form HTML.

Prima di ottenere l'accesso, il client può effettuare solo richieste sulla porta 80 (TCP). Tali richieste vengono inviate ad un "login server", che tipicamente è un Captive Portal. È buona norma, inoltre, che il Captive Portal risieda su un server distinto rispetto a quello che offre la risorsa richiesta e si preoccupi di loggare tutte le richieste pervenute. Ad esempio, una tipica richiesta potrebbe essere la seguente:

GET /index.htm HTTP/1.1
Host: www.example.com

La risposta del server sarà di tipo 511, come si vede in figura:

Figura 4. 511 Network Authentication Required

Alcune considerazioni (di sicurezza) finali

Tutte le HTTP Response contenente gli Status Codes presentati NON DEVONO essere conservate in cache.

È importante inoltre valutare l'utilizzo dei vari codici a seconda della situazioni. Ad esempio, nel caso degli status codes 429 (Too Many Requests) e 431 (Request Header Fields Too Large) potrebbe essere più appropriato "droppare" direttamente le connessioni, piuttosto che visualizzare messaggi.

Interessante il caso del codice 511: generalmente una HTTP Response con status code 511 non proviene dal server indicato nella URL della HTTP Request. Ciò presenta alcune implicazioni dal punto di vista della sicurezza: ad esempio, un attacker potrebbe intercettare cookie o credenziali di autenticazione HTTP inviate da un user agent, oppure manipolare direttamente i cookie. Va detto che, in ogni caso, un qualsiasi Captive Portal che non utilizzi lo status code 511 di fatto presenta lo stesso tipo di problemi.

Per approfondire lo studio e l'evoluzione del protocollo HTTP (che esula dagli scopi del presente articolo) si veda la relativa RFC.

Link utili

• IETF - Additional HTTP Status Codes (draft-nottingham-http-new-status-02)
• Hypertext Transfer Protocol -- HTTP/1.1 (RFC2616)
• Standard for the format of ARPA Internet text messages (RFC822)