2Dove vogliamo arrivare: siti web dinamici Per programmazione lato server si intende quella serie di tecniche che consentono di produrre risorse in tempo reale, che un server web può restituire ai client senza che esista un file statico corrispondente ad esse, ottenendo così dei siti web dinamici. Questo può essere ottenuto tramite programmi in grado di generare, su richiesta, flussi di dati che vanno a costituire formati tipici del Web, come (X)HTML, CSS, JPEG, GIF (ma in linea di principio qualsiasi tipo di file gestibile dal browser). La programmazione lato server è utilizzata per accedere a basi di dati tramite un interfaccia web, per autenticare gli utenti, ecc. In questo modo, si possono costruire applicazioni interattive simili a quelle usuali, per quanto con qualche limitazione (dovuta all interazione tra client e server, che comporta la ricostruzione dell interfaccia ad ogni passo). Questo genere di applicazioni vengono spesso definite applicazioni web e si ritengono costituite dall insieme dei file e directory che compongono il sito web dinamico, includendo quindi sia i programmi lato server che i file (X)HTML, i fogli di stile, le eventuali immagini utilizzate. Una componente fondamentale delle applicazioni web è data dall accesso a basi di dati, in quanto sempre più spesso i dati che costituiscono le pagine web provengono da archivi che li conservano in forma strutturata, sia per facilità di manipolazione che che l oggettiva esigenza di mantenere grandi quantità di dati. L appendice A richiama brevemente alcuni principi relativi alle basi di dati. Poiché l utente può fornire dei dati al server tramite i form (X)HTML, la risorsa creata dal programma sul server spesso dipende proprio da tali dati. Si pensi per esempio all output di un motore di ricerca, costruito dinamicamente sulla base delle parole chiave impostate dall utente ed a partire da una ricerca su un database contenente la descrizione delle pagine web. A questo scopo, è necessario che ci sia un interfaccia ben definita tra server HTTP e programmi fisicamente residenti sulla macchina server, che permetta lo scambio di dati nell una e nell altra direzione: il programma dovrà ricevere i vari dati relativi alla specifica transazione, inclusi gli eventuali parametri forniti dall utente, mentre il server dovrà ricevere la risorsa generata dal programma. Questo capitolo funge da introduzione ai principi generali, che verranno poi approfonditi grazie ai linguaggi PHP e Java nei capitoli successivi. 2.1 Il server web Il server web, di base, è il solo programma server che gestisce il protocollo HTTP. Questo significa che è un daemon in attesa su una porta TCP (per convenzione, la
60 Dove vogliamo arrivare: siti web dinamici Figura 2.1: Il server web e le risorse statiche porta 80, ma può essere configurato in modo da rispondere su altre porte). L attività principale del server è distribuire risorse, secondo le richieste dei client. Le risorse distribuite sono normalmente ospitate in un sottoalbero specifico del file system (a cui il server ha accesso, cfr. figura 2.1), ma possono anche essere generate all atto della richiesta, di solito sulla base di parametri specificati dall utente all interno di un modulo (X)HTML. Per permettere ciò, il server HTTP ha la possibilità di attivare programmi scritti in qualsiasi linguaggio, in grado di manipolare tali parametri e creare un output in una forma trasferibile all utente come se fosse una risorsa statica. A questo scopo si usano varie tecniche cosiddette server-side, descritte nei paragrafi successivi. In ogni caso, anche i programmi che generano dinamicamente le risorse sono ospitati nel sottoalbero, in punti specifici determinati a priori per questioni di sicurezza. La distribuzione di risorse su richiesta non è però l unica azione compiuta dal server web: altri compiti gestionali fanno parte delle sue attività, come l identificazione della risorsa, del suo tipo MIME, l eventuale autenticazione dell utente (poiché è possibile anche proteggere alcune risorse dall accesso pubblico), ed infine la registrazione degli eventi. Per comprendere meglio la complessità della gestione di un server web, esaminiamo come avvengono i vari passi nel server web più diffuso, Apache: 1. Traduzione da URI a nome di file: i server web hanno la possibilità di far corrispondere dei percorsi virtuali a dei percorsi reali nel proprio albero dei do-
2.2 Il protocollo HTTP 61 cumenti; in questi casi, è necessario che in prima battuta gli URI richiesti dai client vengano tradotti. 2. Verifica dell identità dell utente: per quanto non utilizzata spesso, c è sempre la possibilità di concedere l accesso a determinate risorse in modo controllato. Il primo passo è la verifica dell identità dell utente, effettuata tramite username e password nel caso più semplice, oppure tramite firma digitale se si utilizza HTTPS. 3. Verifica dei privilegi di accesso: una volta identificato l utente, bisogna verificare se ha diritto di accedere alla risorsa. 4. Altre forme di autenticazione (per esempio, gestite da moduli che confrontano l utente con dati presenti su basi di dati). 5. Determinazione del tipo MIME dell oggetto richiesto: ciò permette sia di istanziare opportunamente la risposta, sia eventualmente di attivare moduli per la gestione di determinati tipi di documenti. 6. Fixups : estensioni ancora poco utilizzate. 7. Invio della risposta al client. 8. Registrazione degli eventi in appositi file di log (accessi, risorse richieste, eventuali errori). In Apache, ogni passo è gestito da uno o più moduli tramite un apposita API. Parte dei moduli sono sviluppati direttamente dagli sviluppatori di Apache e sono parte del suo codice, altri sono stati prodotti da altri, spesso per la connessione con altri programmi esterni (per lo scripting, CGI, ecc.), ed è possibile aggiungerne ulteriori, sviluppati in proprio, per sviluppare funzionalità particolari. 2.2 Il protocollo HTTP Come già accennato nel paragrafo 1.3, browser e server comunicano tramite il protocollo HTTP. In particolare, il browser invia al server una particolare struttura dati chiamata richiesta HTTP, contenente un metodo e gli eventuali parametri necessari (per esempio, il comando necessario per ricevere un file, di cui si fornisce l URI), e riceve dal server un analoga struttura, detta risposta HTTP, contenente l esito della richiesta, il quale normalmente incorpora il file che poi il browser mostrerà all utente. Il protocollo HTTP è disponibile in tre versioni (0.9, 1.0, 1.1), di cui la più utilizzata è ormai la 1.1. 2.2.1 La richiesta HTTP La richiesta HTTP consiste di due parti: un intestazione (header) ed un corpo (body). L intestazione è costituita da una serie di linee di testo, di lunghezza limitata.
62 Dove vogliamo arrivare: siti web dinamici Tabella 2.1: Metodi HTTP Metodo Richiesta Nota GET GET risorsa HTTP/ver Richiede al server l invio di un file, il cui percorso è indicato dal parametro risorsa. POST POST risorsa HTTP/ver Invia alla risorsa delle informazioni, racchiuse nel corpo della richiesta come coppie attributo=valore. Risorsa normalmente è un programma lato server in grado di elaborare tali informazioni e restituire una nuova risorsa creata dinamicamente, che sarà inclusa nel corpo della risposta HTTP. HEAD HEAD risorsa HTTP/ver Equivalente al GET, solo che il server restituisce esclusivamente l intestazione della risposta HTTP. Utile per diagnostica, o per la verifica della data di modifica di una risorsa. La prima riga contiene la richiesta vera e propria, costituita da un metodo, l URI cui si riferisce la richiesta, e la versione del protocollo utilizzata. Seguono poi alcune righe di testo contenenti delle intestazioni (header), ovvero metadati scambiati tra browser e server. Il corpo della richiesta è separato dall intestazione tramite una linea vuota. Nella richiesta HTTP il più delle volte è vuoto, ma potrebbe contenere dei dati che il browser passa al server (cfr. paragrafo 2.3.3). Supponiamo che l utente abbia cliccato sul browser un link che rimanda all U- RI http://www.dominio.com/dir1/dir2/file.html. Il browser invierà al server www.dominio.com la seguente richiesta HTTP (semplificata): Listato 2.1: Una richiesta HTTP minimale 1 GET /dir1/dir2/file.html HTTP/1.1 2 Host:www.dominio.com I metodi I metodi corrispondono ai comandi che il browser invia al server per ottenere dei servizi. Per lo svolgimento delle funzioni del web server, avremo bisogno almeno di un metodo per richiedere l invio di un file ed uno per inviare i dati eventualmente inseriti dall utente in un form. Ce ne sono però anche altri, molto meno usati ed a volte proprio disabilitati per non incorrere in problemi di sicurezza. I metodi del protocollo HTTP (comuni alle versioni 1.0 e 1.1) sono illustrati nella tabella 2.1. Il parametro risorsa viene ricavato dall URI che si richiede, sottraendo la porzione relativa a protocollo e dominio (che invece viene usato per determinare il server a
2.2 Il protocollo HTTP 63 cui collegarsi); non necessariamente corrisponde esattamente ad un percorso nel file system del server. Il secondo parametro, ver, indica la versione di HTTP usata per la richiesta. Altri metodi sono disponibili a partire dalla versione 1.1, ma sono poco usati; non verranno quindi trattati. 2.2.2 La risposta HTTP La struttura della risposta HTTP inviata dal server al browser è sostanzialmente identica a quella della richiesta: c è un intestazione che contiene un messaggio del server (di successo o fallimento), sotto forma di codice di stato, seguito da eventuali intestazioni (alcune delle quali necessarie all interpretazione della risposta). Poi c è un corpo che invece il più delle volte non è vuoto, ma contiene il file richiesto per esempio tramite il metodo GET. Alla richiesta illustrata nell esempio precedente, il server potrebbe rispondere nel modo seguente: Listato 2.2: Una tipica risposta HTTP 1 HTTP/1.1 200 OK 2 Content-Type: text/html 3 Content-Length: 3451 5 <html> 6 <head> 7... 8 (tutto il file richiesto) 9... I codici di stato del server Non sempre il server sarà in grado di soddisfare la richiesta del browser. Quando non è possibile, risponderà con un codice numerico seguito dalla descrizione testuale del motivo per il quale la richiesta non è stata soddisfatta. Il codice numerico è un numero a 3 cifre, di cui la prima identifica la categoria cui il codice appartiene: 1XX - codici puramente informativi; 2XX - codici che indicano il successo della richiesta da parte del client; 3XX - codici che indicano che la richiesta è stata ricevuta ma è necessaria un ulteriore azione affinché il servizio richiesto sia effettivamente fornito; 4XX - codici che indicano errori nella richiesta; 5XX - codici che indicano errori sul server, o impossibilità di assolvere alla richiesta.
64 Dove vogliamo arrivare: siti web dinamici La tabella 2.2 illustra i codici di stato più frequenti. Tabella 2.2: Codici di stato HTTP Codice Descrizione Nota 100 Continue Il client può continuare con la sua richiesta. 200 OK Risposta usuale per un file correttamente trasferito: la richiesta è stata accolta e il server risponde con i dati richiesti. 201 Created La richiesta è stata servita ed è stata creata una nuova risorsa. 202 Accepted La richiesta è stata accettata ma non ancora servita. 204 No Content Il server ha servito la richiesta, ma non è necessario l invio del corpo del messaggio. Quando il browser riceve questo codice, non ha bisogno di aggiornare il documento visualizzato. 300 Multiple Choices L URI richiesto corrisponde a più documenti (per esempio, un documento disponibile in più lingue). 301 Moved Permanently La risorsa richiesta è stata assegnata definitivamente ad un nuovo URI. 303 See Other La risorsa richiesta si trova in un altro URI specificato nello header Location. 304 Not Modified Il Client ha effettuato una richiesta GET condizionale usando lo header If-Modified-Since, e la risorsa non è stata ancora modificata, per cui il server non ha bisogno di spedirla. 400 Bad Request Richiesta non capita dal server a causa di un errore di sintassi. 401 Authorization Required Questo risultato è dato dallo header WWW- Authenticate per indicare che la risorsa richiede un autorizzazione che non è fornita nella richiesta. 403 Forbidden La richiesta è corretta ma il server si rifiuta di servirla; non dovrebbe essere quindi ripetuta. 404 Not Found Non esiste una risorsa corrispondente all URI richiesto. 405 Method Not Allowed Il metodo specificato nella richiesta non è disponibile per l URI indicato.
2.2 Il protocollo HTTP 65 408 Request Timed Out 413 Request Entity Too Large 414 Request URI Too Long 500 Internal Server Error 501 Not Implemented 503 Service Unavailable 505 HTTP Version Not Supported Il client non ha fornito una richiesta nel tempo massimo di attesa del server. La richiesta è più grande di quel che il server può elaborare. L URI richiesto è troppo lungo per essere interpretato dal server. Il server è in una situazione inaspettata e non può rispondere alle richieste. Il server non è implementato per rispondere correttamente alla richiesta effettuata. Il server non può rispondere causa temporaneo sovraccarico. Il server non supporta la versione del protocollo HTTP utilizzata per fare la richiesta. 2.2.3 Le intestazioni Subito dopo la riga di testo contenente il metodo, richiesta e risposta HTTP usualmente presentano una serie di altre righe contenenti metadati riguardo il client, il server e/o la richiesta stessa. Ogni intestazione è costituita da una parola chiave, seguita dai due punti ed un valore che può anche essere piuttosto complesso. Ciò permette al server di riconoscere la capacità del client ed eventualmente di servirlo di conseguenza, ed al client di conoscere le caratteristiche della risposta ricevuta dal server. Per esempio, nella risposta HTTP appena vista, sono presenti due intestazioni relative alle caratteristiche del corpo della risposta: Content-Type, che dice che il file che segue è di tipo HTML, e Content-length, che ne specifica la lunghezza in byte. Il browser normalmente invia diversi metadati al server, descrivendo le sue capacità, come i tipi di file accettati, le lingue gestite, il tipo di browser ed il sistema operativo, la risoluzione dello schermo, ecc. Ecco una richiesta HTTP particolarmente (ma non esaustivamente!) completa: Listato 2.3: Una richiesta HTTP più completa 1 GET /dir1/dir2/file.html HTTP/1.1 2 Host:www.dominio.com 3 Accept: text/xml,application/xml,application/(x)html+xml,text/ html,text/plain,image/png 4 Accept-language: it,en 5 Accept-charset: ISO-8859-1 6 User-agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; it; rv:1.8.0.5) Gecko/20060723 Firefox/1.5.0.5 7 Referer: http://www.google.it/search?q=un+ottimo+libro&start=0& ie=utf-8