Dispense: 00-intro

Matteo Vaccari > Applicazioni Web

Introduzione

Il web è un meccanismo per la condivisione di informazioni in maniera decentralizzata sulla rete Internet. Nelle intenzioni dei suoi inventori, il web era soprattutto un sistema per condividere documenti statici. C'era l'idea che si potesse tramite un browser anche modificare un documento remoto, ma in generale si pensava che l'interesse del web fosse soprattutto quello di condividere documenti scritti da esseri umani.

Dal punto di vista di un browser, un interazione con un web server non è altro che una richiesta a cui fa seguito una risposta. Non c'è maniera di sapere se il corpo della risposta, che può essere un poema di 100.000 caratteri, era originariamente contenuto in un file statico, oppure è stato composto al momento da un programma che inventa versi poetici a caso. Tutto quello che il browser osserva è una risposta che passa attraverso la rete.

Questa osservazione sta alla base dei documenti dinamici. Se io voglio fornire un servizio web che contiene tutti i titoli dei giornali di oggi, posso redigere ogni giorno un documento html in cui trascrivo manualmente i titoli. Oppure posso scrivere un programma che si collega al servizio web dei vari giornali e copia meccanicamente i titoli in un documento redatto ogni volta al momento. Dal punto di vista dell'utente non si possono distinguere questi due casi.

Se io posso scrivere programmi che redigono documenti HTML sulla base di informazioni arbitrarie, allora si aprono un numero di possibilità. Io posso realizzare un servizio web che pubblica tutti i contenuti di un database, redigendo i documenti in formato HTML in maniera automatica, sulla base dei contenuti correnti del database aggiornati all'ultimo secondo, obbedendo a una mia ricetta su come questi contenuti debbano essere presentati.

Posso fare anche di più: posso scrivere delle form html che permettono ai miei utenti di fornirmi delle informazioni, che potranno, sempre sulla base di mie ricette, essere automaticamente incorporati nella mia base di dati. In questo modo il mio servizio web comincia a somigliare più a un'applicazione tradizionale che non a una libreria di documenti remota. Un'applicazione web dunque non è altro che un'applicazione che usa il web come piattaforma di presentazione; così come un'applicazione Mac potrebbe usare Cocoa o un'applicazione Java potrebbe usare Swing.

Realizzare un'applicazione sul web presenta numerosi vantaggi rispetto alle applicazioni realizzate con le interfacce utente tradizionali. Il primo e più importante vantaggio è che ci si avvale della grande portabilità del web per realizzare applicazioni usabili su praticamente tutti i sistemi operativi. Praticamente ogni sistema operativo esistente dispone di un web browser, e un browser è tutto quello che serve per utilizzare un'applicazione web.

In secondo luogo, un'applicazione web è distribuita e centralizzata. Distribuita perché comunica con qualsiasi computer connesso alla rete IP; centralizzata perché tutte le informazioni vengono conservate sul server. Quindi il web è la piattaforma ideale per le applicazioni client-server

Infine un'applicazione realizzata sul web si aggiorna automaticamente; non c'è bisogno di visitare tutti i computer dei nostri utenti per installare versioni aggiornate del software; perché tutto il software che serve viene scaricato automaticamente dal server. Possiamo stare certi che gli utenti di un'applicazione web usano sempre la versione più aggiornata dell'applicazione.

Fino a pochi anni fa, la maggior parte delle applicazioni che venivano realizzare erano basate su tecnologie client-server proprietarie, con la componente client che doveva essere installata direttamente sul client. Le "applicazioni web" erano un caso speciale, una specie di stranezza. Oggi la situazione è cambiata: le applicazioni web sono diventate la tecnologia di gran lunga più diffusa, tanto che ora quando si parla di "realizzare un'applicazione" nella gran parte dei casi si sottintende "un'applicazione web."

Per questi motivi è importante imparare a realizzare applicazioni web, e soprattutto imparare a realizzarle bene. Per questo è fondamentale conoscere bene i fondamenti della tecnologia web, che sono gli standard HTTP, URI e HTML. Se non si conoscono bene queste basi, è difficile realizzare applicazioni web efficaci.

Il protocollo HTTP e le applicazioni web

Il protocollo HTTP è un protocollo applicativo, che viene implementato in cima a TCP, il quale a sua volta è implementato in cima a IP, che è il protocollo di base di Internet. Come la maggior parte dei protocolli di Internet, il protocollo HTTP è testuale, così che possiamo osservare direttamente i suoi messaggi senza bisogno di programmi di decodifica. Se mettiamo in attesa il programma netcat su una qualsiasi porta TCP del nostro computer, ad esempio la 8080, con il comando

$ nc -l -p 8080

e puntiamo un browser alla URI http://localhost:8080, potremo osservare la richiesta http che viene fatta al server

$ nc -l -p 8080
GET / HTTP/1.1
Host: localhost:8080
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.7,it;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

Possiamo vedere che la richiesta http si compone di due parti: l'intestazione

GET / HTTP/1.1

e una serie di header simili a quelli di un messaggio di posta elettronica.

L'intestazione specifica un metodo, in particolare il metodo GET, un cammino o pathname della risorsa desiderata, in questo caso la radice o root, e la versione di protocollo che viene usata.

Gli header che seguono forniscono un insieme di informazioni aggiuntive, fra cui il tipo di risposta che il nostro browser si attende. Fra questi header vediamo "Accept-Language: en-us,en;q=0.7,it;q=0.3", che specifica che il linguaggio preferito dal mio browser è l'inglese degli USA (en-us). In questo modo un sito multilingua può decidere di mandarmi un documento in inglese in preferenza a un'altra lingua.

Una terza parte della richiesta che in questo caso non vediamo è il corpo (body) della richiesta. Non la vediamo perché in questa particolare richiesta il corpo è vuoto. Ricapitolando una richiesta HTTP si compone di * intestazione * headers * corpo

Anche la risposta HTTP si compone di tre parti.
* La status line * una lista di header * il corpo.

Proviamo a interrogare con netcat il web server Apache che ho installato sulla mia macchina. Digito

$ nc localhost 80

Per collegarmi tramite netcat alla porta 80 del mio elaboratore. Poi digito manualmente le seguenti righe:

GET / HTTP/1.1
Host: localhost

Seguite da due "a capo." Il server risponde come segue

HTTP/1.1 200 OK
Date: Wed, 12 Sep 2007 20:25:50 GMT
Server: Apache/1.3.37 (Unix) PHP/4.4.7
Content-Location: index.html.en
Vary: negotiate,accept-language,accept-charset
TCN: choice
Last-Modified: Fri, 28 Jul 2006 21:32:52 GMT
ETag: "bd330-a71-44ca8284;4620805e"
Accept-Ranges: bytes
Content-Length: 2673
Content-Type: text/html
Content-Language: en

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
 <HEAD>
  <TITLE>Test Page for the SSL/TLS-aware Apache Installation on Web Site</TITLE>

... seguono 83 righe di codice HTML. La prima riga è la status line che ci dice che: * questo server parla la versione 1.1 del protocollo HTTP * la richiesta verrà soddisfatta con successo: questo è il significato del codice di status 200

La scritta "OK" è un semplice commento, ad uso di ficcanaso umani come noi. Se avessimo richiesto una risorsa non disponibile, come ad esempio un cammino "/inesistente", avremmo ricevuto un codice di status differente:

$ nc localhost 80
GET /inesistente HTTP/1.1 
Host: localhost

HTTP/1.1 404 Not Found
Date: Wed, 12 Sep 2007 20:31:17 GMT
Server: Apache/1.3.37 (Unix) PHP/4.4.7
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML><HEAD>
<TITLE>404 Not Found</TITLE>
</HEAD><BODY>
<H1>Not Found</H1>
The requested URL /inesistente was not found on this server.<P>
<HR>
<ADDRESS>Apache/1.3.37 Server at buffy.sciva.uninsubria.it Port 80</ADDRESS>
</BODY></HTML>

In questo caso lo status è 404, e il commento esplicativo dice "Not Found."

Fra gli header, il più importante è il Content-Type; il valore di questo header è il codice di un tipo di documento, secondo lo standard MIME, che è stato inventato per la posta elettronica. In questi due esempi il Content-Type è "text/html", che ci dice che il contenuto è un documento HTML. Questo dice al browser che dovrà interpretarlo come tale. Se invece lo header fosse stato "text/plain", avremmo visto sul browser il sorgente HTML non interpretato. Lo standard HTTP prevede che lo header Content-Type sia sempre obbligatoriamente specificato.

Lo header Content-Length specifica la lunghezza del corpo della risposta. Non è obbligatorio specificarlo, per il server, ma specificandolo si facilita la vita al browser. In questo modo infatti il browser può sapere in anticipo quanta memoria deve allocare per contenere la risposta, cosa che rende più semplice la vita a chi debba scrivere un client HTTP in un linguaggio come il C. Inoltre il Content-Length permette ai browser di mostrare all'utente un indicazione di quanto tempo manchi al termine del download di un documento di grosse dimensioni.

Il protocollo HTTP è client/server: gli attori che partecipano si dividono in web server, che attendono per un tempo indefinito le richieste che arrivano da vari web browser. Per ogni richiesta il server restituisce una appropriata risposta, per cui possiamo dire che il protocollo http è un protocollo richiesta-risposta. Il server è in grado di servire numerose richieste contemporaneamente da numerosi differenti browser. Se un browser inizia una richiesta, ma è lento a leggere la risposta, questo non significa che un altro browser più veloce debba attendere che la richiesta del primo sia stata completamente soddisfatta per poter essere servito.