“Risorsa” è un termine generale che comprende i file ma non è limitato ad essi: è qualunque informazione che possa essere identificata da un URL (la R di URL sta per risorsa). Discuteremo più avanti dell’URL, ma è essenzialmente un metodo per dire di quale risorsa il client necessita (in altre parole l’indirizzo della risorsa) Il tipo più comune di risorsa è il file (una pagina ipertestuale, una immagine), ma una risorsa può anche essere il risultato di una richiesta, l’output di uno script CGI o altro.

Il protocollo HTTP definisce un metodo di interazione client-server ottimizzato per le connessioni brevi e veloci necessarie per le connessione tra client web e server web. Si tratta di un protocollo generico, stateless e leggero.

Generico, significa facilmente estensibile per comprendere servizi di vario tipo, non solo transazione ipertestuali.Stateless significa che, tra una connessione e l’altra, il server non tiene nota della connessione precedente, e quindi tutte le connessioni sono trattate alla stessa maniera, come se si trattasse ogni volta di un nuovo client. Leggero, significa che il client si connette al server solo per il tempo strettamente necessario per trasmettere la risorsa, e quindi chiude la connessione.

Si tratta di un funzionamento molto diverso da altri server, per esempio FTP, in cui la connessione è tenuta aperta per tutto il tempo che l’utente desidera, anche se non c’è nessun file da trasferire.

http://server[:port]/[path/][file]

dove server è l’indirizzo internet del server HTTP (il nome o l’indirizzo IP). port è il numero della porta a cui connettersi: può essere omesso, e in tal caso prende il valore di default 80. Il path indica al server la directory del file richiesto, e file è il nome del file.

Per esempio l’URL

http://www.microsoft.com:80/jobs/consult.htm

chiede di utilizzare il protocollo HTTP per reperire sul server web il cui nome è www.microsoft.com e che risponde alla porta 80 il file consult.htm che sta nella directory jobs.

Più avanti vedremo forme di URL che possono invocare protocolli diversi (per esempio FTP).

Il modello di transazione di HTTP è molto semplice, e questa è la principale ragione per cui si può facilmente estendere.

Una tipica transazione avviene così:

• Il client HTTP (browser) stabilisce una connessione con un server HTTP remoto; le informazioni sul server da contattare e sulla porta da usare sono comprese nel link ipertestuale; il client localizza il server e inizia il processo di connessione.
• Il client spedisce una richiesta; possono essere fatte richieste diverse che possono comprendere anche informazioni come: che tipo di dati il client può trattare, che linguaggio naturale preferisce,che tipo di dati viene spedito al server.
• Il server processa la risposta; a questo punto possono succedere cose diverse; molte risposte sono processate dal server stesso (la maggior parte delle volte il processo consiste nel localizzare un file e restituirlo al cliente); altre vengono passate ad altre applicazioni, soprattutto CGI; queste applicazioni rispondono al server il quale passa le informazioni al client.
• Il server risponde qualcosa al client; potrebbe essere il file richiesto, una semplice conferma che la richiesta è stata processata, oppure un messaggio di errore; in HTTP sono definiti diversi codici per comunicare cosa è successo; la richiesta potrebbe anche contenere informazioni su cosa il server sa fare e quali tipi di dati sa ritornare al client
• Il server chiude la connessione; i primi protocolli, come telnet e ftp, erano stati progettati con l’idea che l’utente si collegasse ad un sistema remoto per un periodo di tempo esteso, trasmettendo comandi diversi e tenendo la connessione aperta; nel caso del web invece è probabile che la prossima connessione avvenga in un tempo abbastanza successivo alla precedente, e/o che la richiesta sia diretta ad un altro server; in tal caso non c’è vantaggio nel tenere la connessione aperta o mantebnere informazioni sul client; quindi HTTP è stato progettato per chiudere la connessione appena ha finito di processare una richiesta.

Forma generale

Client e server HTTP discutono tra loro con il protocollo HTTP. Una richiesta HTTP, fatta dal client al server, è di questo tipo generale:

<METHOD> <URI> “HTTP/1.0” <CRLF>
<Header>: <Value>
...
<Header>: <Value>
<CRLF>
<BODY>

E il server risponde in questo modo

HTTP/1.0 <STATUS_CODE> <REASON><CRLF>
<Header>: <Value>
...
<Header>: <Value>
<CRLF>
<BODY>

METHOD è una singola parola che dice al server che tipo di richiesta viene fatta. URI è una parte dell’URL che essenzialmente dice il percorso e il nome della risorsa richiesta. CRLF sono due caratteri ASCII (13 e 10) di a capo e fine linea. Le righe di Header successive possono comprendere informazioni aggiuntive, come il nome del software client (User-Agent) e i tipi di MIME che il client può trattare. BODY sono dati opzionali che possono essere aggiunti in qualche richiesta.

La risposta comprende, oltre alla versione di HTTP, uno STATUS_CODE cioè un codice ddi tre cifre che indica lo stato della risposta e REASON, il motivo della risposta. BODY contiene i dati che vengono trasferiti al client.

Esempio

Se un browser vuole ricevere il file specificato dall’URL

http://www.somehost.com/abc/saluti.html

dapprima apre una connessione con l’host www.somehost.com alla porta 80 (porta di default, poiché nell’URL non è specificata alcuna porta). Quindi spedisce attraverso la connessione la richiesta

GET /abc/saluti.html HTTP/1.0
From: someuser@jmarshall.com
Accept: text/html
Accept: text/plain
Accept: image/gif
Accept: */*
User-Agent: Netscape 1.1N PPC
[linee vuote]

Il server risponde con qualcosa di questo tipo, trasmesso attraverso la stessa connessione

HTTP/1.0 200 OK
Date: Fri, 31 Dec 1999 23:59:59 GMT
Content-Type: text/html
Content-Length: 1354


<html>
<body>
<h1>Ciao a tutti.</h1>
(more file contents)
...
</body>
</html>

Dopo aver mandato la risposta il server chiude la connessione.

Nella richiesta, GET è il metodo di richiesta, significa “dammi questa risorsa”. Attualmente sono specificati nel protocollo HTTP sette metodi, ma solo due o tre sono comunemente usati (oltre a GET, POST e HEAD). abc/saluti.html è il cammino e il nome del file richiesto (URI, una parte dell’URL). La versione HTTP è sempre della forma HTTP/x.x. Accept viene utilizzato per indicare la lista dei dati che il client può trattare. In questo caso testo (sia con tag HTML che senza tag) e immagini GIF.

Nella risposta, 200 è il codice di stato (indica che la richiesta ha avuto buon fine), OK è la spiegazione in lettere del codice di stato. Seguono altre informazioni e quindi l’intera pagina HTML richiesta.

GET è il metodo più usato per chiedere informazioni a un server. Quando un utente fa clic su un link di una pagina web, il client spedisce una richiesta GET per avere l’URL (cioè la risorsa) specificato nel link. Il metodo GET può anche essere usato per trasmettere una richiesta ad una applicazione CGI che, come risultato del suo processo, restituisce dati. In tal caso i dati in ingresso all’applicazione CGI vengono aggiunti in fondo all’URL (cioè all’indirizzo dell’applicazione) separati da un punto di domanda (?).

POST è il metodo usato per spedire ad un server dati devono essere processati in qualche modo, per esempio da una applicazione CGI. Le differenze rispetto ad un GET sono queste:

• Nel body della richiesta c’è un blocco di dati che vengono spediti. Ci sono normalmente degli header extra che descrivere il body, come Content-Type: e Content-Length:.
• L’URI richiesto non è un risorsa da recuperare: è normalmente un programma che riceve in input i dati che vengono spediti.
• La risposta HTTP è normalmente l’output di un programma, non un file statico.

• 200: OK, la richiesta è stata processata e i dati vengono spediti
• 204: No Content, la richiesta è stata processata ma non ha avuto risposta
• 301: Moved Permanently: il file specificato è stato permanentemente spostato in un’altra locazione
• 403: Forbidden: il client non è autorizzato a ricevere i dati richiesti
• 404: Not Found: i dati specificati nell’URL non sono stati trovati
• 500 Internal Server Error: il server è incorso in un errore inaspettato che non ha permesso di completare la richiesta

• Le transazioni multiple possono avvenire durante una singola connessione persistente (quindi aumenta la velocità)
• Supporto per la cache (aumenta la velocità e si risparmia ampiezza di banda)
• Chunking encoding: si può spedire una riposta prima che sia nota la sua lunghezza totale (aumenta la velocità)
• Con un singolo indirizzo IP si possono servire domini multipli.