HTTP
Risposte HTTP

Parametri

Formato di risposta di base

Quando un server HTTP riceve una richiesta HTTP ben formata, deve elaborare le informazioni contenute nella richiesta e restituire una risposta al client. Una semplice risposta HTTP 1.1 può apparire come una delle seguenti, solitamente seguita da un numero di campi di intestazione e, eventualmente, da un corpo di risposta:

HTTP/1.1 200 OK \r\n

HTTP/1.1 404 Not Found \r\n

HTTP/1.1 503 Service Unavailable \r\n

Una semplice risposta HTTP 1.1 ha questo formato:

HTTP-Version Status-Code Reason-Phrase CRLF

Come in una richiesta, HTTP-Version indica la versione del protocollo HTTP in uso; per HTTP 1.1 questa deve sempre essere la stringa HTTP/1.1 .

Status-Code è un Status-Code a tre cifre che indica lo stato della richiesta del cliente. La prima cifra di questo codice è la classe di stato , che colloca il codice di stato in una delle 5 categorie di risposta ^[1] :

• 1xx Informativo : il server ha ricevuto la richiesta e l'elaborazione continua
• 2xx Successo : il server ha accettato ed elaborato la richiesta
• Reindirizzamento 3xx : è necessario un ulteriore intervento da parte del cliente per completare la richiesta
• Errori del client 4xx : il client ha inviato una richiesta che non era valida o che non può essere soddisfatta
• Errori del server 5xx : la richiesta era valida, ma al momento il server non è in grado di soddisfarla

Reason-Phrase è una breve descrizione del codice di stato. Ad esempio, il codice 200 ha una frase di motivazione di OK ; il codice 404 ha una frase di Not Found . Un elenco completo di frasi di motivazione è disponibile in Parametri, sotto o nelle specifiche HTTP .

La linea termina con una coppia di trasporto a riga di ritorno, solitamente rappresentata da \r\n .

Intestazioni aggiuntive

Come una richiesta HTTP, una risposta HTTP può includere intestazioni aggiuntive per modificare o aumentare la risposta che fornisce.

Un elenco completo delle intestazioni disponibili è definito nel §6.2 della specifica . Le intestazioni più comunemente utilizzate sono:

• Server , che funziona come un'intestazione di richiesta User-Agent per il server;
• Location , che viene utilizzata sulle risposte di stato 201 e 3xx per indicare un URI da reindirizzare a; e
• ETag , che è un identificativo univoco per questa versione della risorsa restituita per consentire ai client di memorizzare nella cache la risposta.

Le intestazioni di risposta vengono dopo la riga di stato e, come per le intestazioni delle richieste, sono formate come tali:

Name: Value CRLF

Name fornisce il nome dell'intestazione, come ETag o Location , e Value fornisce il valore che il server sta impostando per quella intestazione. La linea termina con un CRLF.

Una risposta con le intestazioni potrebbe essere simile a questa:

HTTP/1.1 201 Created \r\n
Server: WEBrick/1.3.1 \r\n
Location: http://example.com/files/129742 \r\n

Corpi dei messaggi

Come per i corpi delle richieste , le risposte HTTP possono contenere un corpo del messaggio. Ciò fornisce dati aggiuntivi che il cliente elaborerà. In particolare, 200 risposte OK a una richiesta GET ben formata dovrebbero sempre fornire un corpo del messaggio contenente i dati richiesti. (Se non ce n'è, 204 No Content è una risposta più appropriata).

Un corpo del messaggio è incluso dopo tutte le intestazioni e un doppio CRLF. Per quanto riguarda le richieste, la sua lunghezza in byte dovrebbe essere data con l'intestazione Content-Length . Una risposta positiva a una richiesta GET, quindi, potrebbe essere simile a questa:

HTTP/1.1 200 OK\r\n
Server: WEBrick/1.3.1\r\n
Content-Length: 39\r\n
ETag: 4f7e2ed02b836f60716a7a3227e2b5bda7ee12c53be282a5459d7851c2b4fdfd\r\n
\r\n
Nobody expects the Spanish Inquisition.