|
|
I messaggi http request o response sono composti da una testata e da un body; si inizia con una start-line e seguono zero o più header (intestazioni) del messaggio, poi una riga vuota ed in seguito c'è il corpo del messaggio, nel quale si può trasferire sempre qualcosa di binario senza bisogno di successive codifiche. Vediamo ora in dettaglio come è strutturata una request. L richiesta di un client HTTP è la prima fase di una transazione HTTP. Le richieste di un client appartengono a due categorie fondamentali: una richiesta semplice (simple) ed una completa (full). L'HTTP chiama i suoi comandi metodi. L'unico metodo (o comando) utilizzato dalla richiesta semplice è il GET. Quindi con la richiesta semplice il server localizza e trasferisce l'oggetto che l'URI specificato identifica. Un esempio di richiesta semplice è:
GET http://www.dacrema.com
Una richiesta completa (full-request) inizia con una request-line, poi ci sono vari headers che si differenziano in tre sotto tipi di header:
General-header: possono essere presenti sia nella request che nella response. Queste intestazioni si applicano a tutto il messaggio e hanno i l seguente aspetto:
Per esempio Transfer-Encoding riguarda la compressione e si riferisce a tutto il messaggio. Questa può essere chunked: vuol dire che il trasferimento avviene a pezzettini nel caso che la risposta sia lunga. Per spiegazioni riguardanti gli altri termini elencati si rimanda alla RFC 2068.
Request-header: è solo presente in una request. Queste intestazioni hanno i l seguente aspetto:
Vediamo il significato di alcuni request-headers:
Accept specifica i tipi di file accettati come risposta.
Accept-Encoding specifica il metodo di compressione accettato.
Accept-Language specifica i linguaggi accettati (nel caso in cui un documento sia disponibile in più lingue).
Authorization e Proxy Authorization sono utilizzati per inviare le credenziali dell'utente e servono per entrare in siti privati dove viene chiesto user-name e password;
From specifica l'indirizzo e-mail del richiedente.
Host specifica l'indirizzo del server a cui è indirizzata la richiesta.
If-Modified-Since restituisce il documento solo se è stato modificato recentemente.
User-Agent specifica nome e versione del programma client
Vediamo alcuni esempi:
Accept-Encoding: compress, gzip
Noi stiamo chiedendo una risorsa e con l'accept specifichiamo al server cosa desideriamo avere. La mia macchina è capace di capire messaggi in formato compresso, quindi se il server è in grado, gli chiedo se mi comprime il file che gli ho chiesto col compress o col gzip, in modo che il trasferimento sia più veloce, poi ci penserà la mia macchina a decomprimerlo.
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Richiedo il file possibilmente nel formato di charset iso-8859-5, altrimenti (come seconda preferenza) nel formato unicode 1-1. Il q=0.8 serve per specificare che livello di preferenza ho sulle opzioni. Se non c'è nulla sono equivalenti e il server sceglie a caso. In questo caso q=0.8 si riferisce alla seconda opzione, la prima ha q=1 sottintesa.
Accept: text/plain;q=0.5, text/html, text/x-dvi;q=0.8, text/x-c
Richiedo la risorsa nel formato html o x-c, altrimenti, se il server non le ha disponibili, nel formato x-dvi, infine, come ultima scelta, nel formato plain. Questo consente al server di variare la sua risposta in base alle nostre opzioni.
Entity-header: si può trovare sia in una request che in una response, ma sono riferiti alle entità, cioè a quello che è riportato nel message-body.
Nella richieste completa (full-request) si deve specificare nella request-line la versione dell'HTTP usata perchè la URI dipende dalla versione, e anche la presenza obbligatoria o meno di certi header dipende dalla versione. Un URL può essere lunga quanto si vuole, ma certi server accettano solo URL fino a 256 caratteri (che sono già abbastanza!). I metodi più importanti sono:
OPTIONS: è il metodo più semplice di tutti. Serve per sapere cosa possiamo fare con la risorsa che stiamo richiedendo. Nell'esempio riportato di segutio vi è riportata una request di tipo OPTIONS e la relativa response del server. Si può notare come il server elenchi le opzioni ammesse per la risorsa specificata nella request (index.html), cioè i metodi con cui si può accedere ad essa, che sono GET, HEAD, OPTIONS, TRACE
Se avessi fatto la stessa richiesta OPTIONS ad un programma CGI, avrei ottenuto “Allow: POST” Se avessi scritto: OPTIONS http://192.168.11.66/*, avrei ottenuto le opzioni del server specificato.
GET serve per avere una risorsa come risposta. Notare che vi sono due tipi di GET, il conditional get ed il partial get, che hanno la stessa sintassi, solo che nel primo c'è <header If> e una condizione, nel secondo c'è solo <header Range>. Ad esempio se facciamo un GET seguito da <header If modified since> e una data, ci arriva come risposta la pagina richiesta solo se tale pagina nel server è stata modificata dopo la data specificata nella richiesta, altrimenti ci viene risposto che tale pagina non è stata modificata. Questa opzione è utile per il proxy per l'aggiornamento delle pagine nella sua cache.
Il partial get è utile nel caso in cui, una volta inoltrata la request al server, questo ci risponde iniziando a mandarci la risorsa desiderata; ma se durante il trasferimento per qualche motivo la connessione cade, possiamo rifare la stessa richiesta e il server ricomincia a risponderci da dove era stato interrotto.
HEAD è simile al GET e serve per trasferire solo la testata della risposta, non il body. L'header ricevuta è identica a quella che si avrebbe col GET. A differenza del metodo GET, HEAD non ammette condizioni sul trasferimento dei dati. Si possono quindi avere informazioni sul file specificato, per esempio sapere quando è stato modificato, la sua lunghezza, il tipo di file,ecc. Questo comando è utilizzato da alcuni software per controllare la validità degli hyperlink contenuti nei documenti HTML.
POST non serve per chiedere risorse, anche se il server può mandare una risposta che può contenere un messaggio, ad esempio un'altra pagina HTML. Questo può servire per fare FORMs concatenate: in questo caso si manda la seconda FORM in risposta alla prima.
PUT è un metodo molto simile al POST, ma concettualmente diverso. Anche il PUT serve a mandare dati dal client al server, però il POST serve ad aggiungere o modificare i dati nel server (nel suo database), il PUT serve per aggiungere dei path, cioè aggiungere delle risorse.
Tutto quanto riportato in questa pagina è a puro scopo informativo personale. Se non ti trovi in accordo con quanto riportato nella pagina, vuoi fare delle precisazioni, vuoi fare delle aggiunte o hai delle proposte e dei consigli da dare, puoi farlo mandando un email. Ogni indicazione è fondamentale per la continua crescita del sito.