Chapter 23. Il server web Apache / 23.8. Contenuti dinamici | ||||
|---|---|---|---|---|
 | 23.7. Apache in azione | 23.9. Host virtuali |  | |
Chapter 23. Il server web Apache / 23.8. Contenuti dinamici | ||||
|---|---|---|---|---|
| 23.7. Apache in azione | 23.9. Host virtuali | | |
Apache offre una serie di possibilità per fornire ad un client dei contenuti dinamici. Per contenuti dinamici si intendono pagine HTML create in base alla elaborazione di dati di input variabili del client. Un esempio noto sono i motori di ricerca che dopo aver immesso uno o più termini eventualmente collegati tramite degli operatori logici come "AND'' oppure "OR'' ritornano un elenco di pagine che contengono il termine o i termini indicati.
Con Apache vi sono tre modi per creare dei contenuti dinamici:
Si tratta di direttive embedded nelle pagine HTML tramite dei commenti particolari. Apache analizza il contenuto dei commenti e emette il risultato quale parte della pagina HTML.
Qui vengono eseguiti dei programmi che risiedono all'interno di determinate directory. Apache consegna a questi programmi i parametri trasmessi dal client, e ritorna l'output del programma al client. Questo modo di programmare è relativamente semplice, anche perché si possono modificare i tool della riga di comando esistenti in modo che accettino dell'input di Apache e che gli ritornano l'output.
Apache offre delle interfacce per poter eseguire dei moduli come parte del processo di elaborazione, ed inoltre consente a questi programmi di accedere ad informazioni importanti come la request o l'intestazione HTTP. Ciò rende possibile integrare dei programmi nel processo di elaborazione che non sono solo in grado di creare dei contenuti dinamici ma anche di assumere altre funzioni (p.es. autenticazione). Programmare questo tipo di moduli richiede una certa abilità; i vantaggi che ne conseguono sono alte prestazioni e possibilità che vanno ben oltre a quanto offerto dagli SSI e CGI.
Mentre gli script CGI vengono eseguiti da Apache (con l'ID dell'utente del loro proprietario), per i moduli viene utilizzato un interprete embedded in Apache che sotto l'ID del server web è permanentemente in esecuzione, per tal ragione si usa l'espressione l'interprete è “persistente”. In questo modo non deve venire inizializzato e terminato un proprio processo per ogni richiesta (cosa che crea un overhead considerevole per l'amministrazione dei processi e della memoria), lo script invece viene semplicemente consegnato all'interprete già in esecuzione.
Lo svantaggio comunque è rappresentato dal fatto che mentre gli script eseguiti tramite CGI sono abbastanza tolleranti nei riguardi di errori di programmazione, questa caratteristica non è data quando si ricorre ai moduli. Il motivo è dovuto alla circostanza che i comuni errori negli script CGI, come la negazione di risorse e memoria, non comportano delle particolari conseguenze, visto che dopo l'elaborazione della richiesta questi programmi vengono terminati e lo spazio di memoria negato in precedenza dal programma, a causa di un errore di programmazione, è nuovamente disponibile. Quando si utilizzano invece dei moduli gli effetti degli errori di programmazione si accumulano, dato che l'interprete è permanentemente in esecuzione. Se non si riavvia il server, l'interprete girerà per mesi interi, e così con il tempo si faranno sentire gli effetti di richieste negate o eventi simili.
Server Side Includes sono delle direttive embedded in commenti particolari che vengono eseguiti da Apache. Il risultato viene integrato subito nell' output. Un esempio: potete farvi indicare la data attuale con <!--#echo var="DATE_LOCAL" -->; laddove # indica l'inizio del commento e <!-- è l' indicazione per Apache, che si tratta di una direttiva SSI e non di un solito commento.
Gli SSI possono essere abilitati in modi diversi. La variante più semplice consiste nell' eseguire una ricerca dei SSI nei file eseguibili. L'altra possibilità consiste nello stabilire il tipo di file nei quali cercare gli SSI. Entrambi gli approcci vengono illustrati nella sezione Section 23.6.2.16, “Server Side Includes (SSI)”.
CGI è l'abbreviazione di “Common Gateway Interface”. Tramite la CGI il server non fornisce semplicemente una pagina HTML statica, ma esegue un programma che mette a disposizione la pagina. In questo modo possono venir create delle pagine che sono il risultato di un calcolo, per esempio il risultato di una ricerca in una banca dati. Al programma che viene eseguito si possono consegnare degli argomenti in modo che ritorna in risposta una pagina personalizzata in base alla richiesta.
Il vantaggio della CGI sta nella sua semplicità. Il programma deve solo risiedere in una determinata directory, e il server web lo eseguirà proprio alla stregua di un programma dalla riga di comando. L'output del programma sul canale standard di emissione (stdout) il server lo inoltra semplicemente al client.
I parametri di immissione possono essere consegnati al server con GET oppure con POST. Il modo in cui il server consegna i parametri allo script dipende dal metodo utilizzato. Nel caso di POST il server passa i parametri al programma tramite il canale standard di input (stdin) (proprio come se il programma venisse avviato in una console).
Nel caso di GET il server consegna i parametri al programma tramite la variabile di ambiente QUERY_STRING.
In linea di massima i programmi CGI possono essere scritti in ogni linguaggio di programmazione. Di solito vengono utilizzati a tale scopo dei linguaggi di scripting (linguaggi interpretati) come Perl oppure PHP; per CGI che pone l'accento sulla velocità si propone C oppure C++.
Apache si aspetta questi programmi in una determinata directory (cgi-bin). Questa directory si lascia impostare nel file di configurazione, si veda la sezione Section 23.6, “Configurazione”.
Inoltre si possono stabilire ulteriori directory in cui Apache debba eseguire le sue ricerche di programmi eseguibili. Questo comporta un certo rischio in termini di sicurezza, visto che ogni utente potrà far eseguire da Apache dei programmi (possibilmente nocivi). Se invece i programmi eseguibili sono consentiti solo in cgi-bin, l'amministratore potrà verificare più facilmente chi vi archivia quali script e programmi, ed eventualmente se si tratta di file che possono arrecare danno.
Vi sono una serie di moduli per Apache. Tutti i moduli descritti di seguito sono disponibili sotto forma di pacchetti in . Il termine modulo ha in questa sede due accezioni: da una parte vi sono moduli che possono essere integrati in Apache e assumere una determinata funzione, come ad esempio i moduli che presenteremo di seguito per integrare linguaggi di programmazione in Apache.
Dall'altra, in ambito dei linguaggi di programmazione, si parla di moduli per indicare una serie di funzionalità, classi e variabili. Questi moduli vengono integrati in un programma per offrire una determinata funzionalità. Un esempio è rappresentato dai moduli CGI presenti in tutti i linguaggi di programmazione che facilitano la programmazione di applicazioni CGI mettendo a disposizione dei metodi per leggere dei parametri di request ed emettere del codice HTML.
Perl è un linguaggio di scripting molto diffuso e collaudato. Vi è una vastità di moduli e librerie per Perl (tra l'altro anche una libreria per estendere il file di configurazione di Apache). La home page di Perl è http://www.perl.com/. Nel Comprehensive Perl Archive Network (CPAN) troverete una serie di librerie per Perl http://www.cpan.org/.
Per configurare mod_perl in , basta installare il relativo pacchetto (si veda la sezione Section 23.5, “Installazione”). Le registrazioni necessarie per Apache sono già incluse nel file di configurazione, si veda /etc/apache2/mod\_perl-startup.pl. Per raccogliere delle informazioni su mod_perl visitate il seguente sito:http://perl.apache.org/
Gli script CGI possono essere lanciati come script mod_perl invocandoli attraverso un'URL diversa. Il file di configurazione contiene degli alias che rimandano alla stessa directory, e che lanciano gli script ivi contenuti tramite CGI oppure tramite mod_perl. Tutte le registrazioni sono già presenti nel file di configurazione. L'alias per CGI è:
ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/"
Le registrazioni e per mod_perl sono:
<IfModule mod_perl.c> # Provide two aliases to the same cgi-bin directory, # to see the effects of the 2 different mod_perl modes. # for Apache::Registry Mode ScriptAlias /perl/ "/srv/www/cgi-bin/" # for Apache::Perlrun Mode ScriptAlias /cgi-perl/ "/srv/www/cgi-bin/"; </IfModule>
Servono anche le seguenti registrazioni per mod_perl che comunque sono già presenti nel file di configurazione.
# # If mod_perl is activated, load configuration information # <IfModule mod_perl.c> Perlrequire /usr/include/apache/modules/perl/startup.perl PerlModule Apache::Registry # # set Apache::Registry Mode for /perl Alias # <Location /perl> SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI PerlSendHeader On </Location> # # set Apache::PerlRun Mode for /cgi-perl Alias # <Location /cgi-perl> SetHandler perl-script PerlHandler Apache::PerlRun Options ExecCGI PerlSendHeader On </Location> </IfModule>
Queste registrazioni creano gli alias per i modi Apache::Registry e Apache::PerlRun. Ecco in cosa differiscono:
Tutti gli script vengono compilati e mantenuti nella cache. Ogni script viene generato come contenuto di una subroutine. Anche se questo produce degli effetti positivi dal punto di vista della performance, lo svantaggio è che gli script devono essere programmati in modo impeccabile visto che le variabili e le subroutine permangono anche tra chiamate diverse. Bisogna resettare le variabili affinché possano essere utilizzate nuovamente alla prossima chiamata. Se per esempio il codice della carta di credito di un cliente viene salvato in una variabile di uno script per l'online banking, potrebbe accadere che il codice ricompaia quando è un altro cliente ad utilizzare l'applicazione ed ad avviare lo stesso script.
Gli script vengono ricompilati ad ogni nuova richiesta, in modo che le variabili e le subroutine scompaiono dal name space tra una chiamata e l'altra. Il name space è l'insieme dei nomi di variabili e nomi di routine definiti dall'esistenza di determinato script. Dunque con Apache::PerlRun non bisogna porre particolare attenzione ad una programmazione senza sbavature, dato che le variabili all'avvio dello script vengono inizializzate ex novo e quindi non possono contenere dei valori risalenti a chiamate precedenti. Questo va a discapito della velocità, ma è comunque più veloce di CGI visto che non bisogna lanciare un processo per l'interprete. Apache::PerlRun si comporta alla stregua di CGI.
PHP è un linguaggio di programmazione ideato appositamente per server web. A differenza di altri linguaggi i cui i comandi si trovano in determinati file detti script, i comandi di PHP (similmente agli SSI) si trovano embedded ovvero contenuti in una pagine HTML. L'interprete PHP processa i comandi PHP ed integra il risultato dell'elaborazione nella pagina HTML.
La home page di PHP è http://www.php.net/.
Il pacchetto mod_php4-core va installato in ogni caso, per Apache 2 inoltre il pacchetto apache2-mod_php4.
Python è un linguaggio di programmazione orientato agli oggetti con una sintassi chiara e ben leggibile. Una particolarità di questo linguaggio è che la struttura del programma dipende dall'indentazione. I singoli blocchi non vengono definiti da parentesi graffe o simili (come in C e Perl) oppure da indicazioni begin e end, è il grado di indentazione a svolgere questo ruolo.Installate il pacchetto apache2-mod_python.
Per saperne di più, visitate il sito http://www.python.org/. Per maggior informazioni su mod_python visitate il sito http://www.modpython.org/.
Ruby è un linguaggio di programmazione di alto livello orientato agli oggetti relativamente recente che presenta delle similitudini sia con Perl che con Python, e che si adatta benissimo per script. La sintassi chiara e ben strutturata ricorda Phyton, mentre coloro che apprezzano Perl gradiranno (gli altri meno) la presenza delle abbreviazioni tipici di Perl. In termini di concetto di base Ruby ricorda Smaltalk.
La home page di Ruby:http://www.ruby-lang.org/. Anche per Ruby vi è un modulo Apache, ecco la home page: http://www.modruby.net/.
