Introduzione

Parte con questa puntata una serie di articoli dedicati a mod_perl trait d'union tra due dei più importanti progetti open source: Perl e Apache. Vedremo come mod_perl possa aiutare a creare avanzate e veloci applicazioni web destinate ad un elevato traffico in maniera rapida e facile. Conoscenze richieste quindi sono il Perl e Apache ai quali la rivista ha dedicato tra l'altro numerosi ed esaustivi articoli.

Non è necessario, ma ricordiamo che Il Perl è il più diffuso linguaggio di scripting per l'amministrazione di sistemi Unix/Linux e di gran lunga il più utilizzato per le web application e Apache e il web server leader con oltre il 65% di installazioni sul totale dei web server installati nel mondo (fonte http://www.netcraft.com).

Che cosa è mod_perl?

In breve, mod_perl è un software realizzato nel 1996 da Doug MacEachern, uno dei membri dell'Apache Software Foundation, che incorpora un interprete Perl nel server HTTP Apache. I vantaggi di questa integrazione sono molteplici:

1. l'interprete del Perl fa parte del processo Apache e gli script Perl possono essere eseguiti molto rapidamente: infatti l'interprete Perl non deve essere lanciato per ogni invocazione dello script e, a seconda della configurazione, i moduli del Perl e gli script possono essere interamente o parzialmente precompilati e rimanere residenti in memoria;
2. lo sviluppatore ha accesso alla API completa di Apache. Questo permette di realizzare estensioni del server (cioè moduli Apache) in Perl piuttosto che in C, ottenendo prestazioni comparabili;
3. Apache può essere configurato usando il linguaggio Perl all'interno delle sezioni <Perl></Perl> nel file di configurazione httpd.conf;
4. sono stati sviluppati centinaia di moduli Apache/mod_perl che coprono praticamente tutto. Ciò significa che, in molti casi e possibile installare semplicemente il modulo adatto mettendo a fuoco le proprie risorse sui bisogni specifici dell'applicazione.

Installare mod_perl

mod_perl è un modulo Apache. Requisito necessario quindi è Apache. La prima cosa da verificare è il tipo di installazione Apache che abbiamo sulla nostra macchina. Senza esulare dal tema dell'articolo accenniamo al fatto che a partire dalla versione 1.3, Apache supporta due tipi di compilazione e installazione: statica e dinamica.

Nel primo caso tutti i moduli vengono linkati all'interno di un unico eseguibile rendendo necessaria la ricompilazione ad ogni modifica e/o aggiunta di moduli al server. Nella seconda modalità, detta anche DSO (Dinamyc Shared Object), il caricamento dei moduli avviene run-time col vantaggio che, oltre ad ottenere un eseguibile molto più piccolo, i moduli possono venire modificati, compilati e aggiunti senza dovere ricompilare e reinstallare il server Apache stesso ogni volta; inoltre con un'unica compilazione e installazione è possibile, a seconda delle necessità, avviare diverse istanze del server (ad esempio un "httpd" con mod_perl, un "httpd" col supporto PHP, ecc) utilizzando differenti file di configurazione. Per verificare tutto ciò è sufficiente analizzare l'output del comando:

   %> httpd -l

e vedere se tra la lista dei moduli ci sia anche la voce mod_so.c, il modulo Apache responsabile della gestione DSO

Figura 1. Lista dei moduli compilati staticamente in httpd

In tal caso, dopo esservi procurati l'ultima versione del mod_perl, attualmente la 1.26 (da http://perl.apache.org), compiliamo ed installiamo mod_perl come modulo dinamico:

   %> tar -zxvf mod_perl-1.26.tar.gz 
   %> cd mod_perl-1.26
   %> perl Makefile.PL \ 
      USE_APXS=1 \ 
      WITH_APXS=/path/to/apache_1.3.xx/bin/apxs \ 
      EVERYTHING=1 
   %> make 
   %> make test 
   %> make install 

Nota: Nelle distribuzioni linux RedHat (almeno fina alla 7.0) il tool "apxs" non è installato di default e occorre quindi installarlo manualmente tramite il pacchetto RPM apache-devel-1.3.xx.i386.rpm con il comando:

   %> rpm -i path/to/apache-devel-1.3.xx.i386.rpm

Il pacchetto in questione si trova nel CD-ROM RedHat nella directory RedHat/RPMS

Nel caso invece che l'Apache installato sulla macchina sia statico verifichiamo se è stato compilato anche il modulo mod_perl. Con il solito comando "httpd -l" verifichiamo che nell'output sia presente la linea mod_perl.c. In caso negativo occorre compilare e installare nuovamente Apache. Vale la pena allora di compilarlo in modalità DSO per beneficiare dei vantaggi accennati in precedenza.

Brevemente (ma si rimandano agli articoli dedicati ad Apache su Linux & C, nonche ai vari file README ed INSTALL presenti nella distribuzione per una descrizione più dettagliata) la maniera più veloce per compilare Apache in modalità dinamica è la seguente:

   %> tar -xzvf apache_1.3.xx.tar.gz
   %> cd apache_1.3.xx
   %> ./configure --prefix=/path/to/install/apache_1.3.xx \
      --enable-shared=max \
      --enable-module=<modulo aggiuntivo> \
      --enable-shared=<modulo aggiuntivo>
   %> make
   %> make install

Con la direttiva "--enable-shared=max" abilitiamo il supporto DSO e compiliamo in modalità dinamica tutti i moduli standard. Con la coppia di direttive "--enable-module" e "--enable-shared" abbiamo poi la possibilità di compilare ed installare in modalità DSO altri utili moduli (compresi nella distribuzione ma non compilati di default) come il "mod_rewrite", "mod_usertrack", ecc

Possiamo quindi compilare ed installare mod_perl come descritto precedentemente.

Maggior velocità agli script Perl CGI

Il primo e forse maggior beneficio evidente dell'uso di mod_perl è che crea un veloce ambiente di esecuzione per il codice Perl delle applicazioni già realizzate.

Agli albori del Web, l'unico modo di creare applicazioni che generassero pagine dinamiche (ad eccezione delle Server Side Includes) era l'interfaccia CGI o Common Gateway Interface. Nel modello CGI, quando uno script Perl viene richiesto da un client, il server Web deve avviare l'interprete Perl, l'interprete quindi compila lo script, lo esegue e trasmette il risultato di nuovo al server che interrompe l'interprete e infine trasmette il risultato al client. La spesa di risorse (memoria e CPU) associata in questo modello è evidente se si considera il fatto che questo ciclo è ripetuto per ogni richiesta a quel determinato script.

Il principale difetto di questo modello è la scarsa scalabilita. Supponiamo infatti che si stia usando il Perl per alcuni script CGI: come il numero di visite aumenta e l'applicazione da semplice script (o raccolta di script) di poche linee evolve ad una più seria applicazione di decine di migliaia di linee di codice per includere via via sempre piu caratteristiche, presto ci si accorgerà che le prestazioni degraderanno in maniera esponenziale. Ecco che allora mod_perl offre una facile soluzione anche per semplici script Perl consentendo un aumento immediato in velocita ed in scalabilità.

Vediamo ora come mod_perl offra due possibilità per velocizzare l'esecuzione degli script Perl già realizzati: Apache::Registry e Apache::PerlRun. In entrambe le modalità non sono quasi mai necessarie modifiche agli script. Analizziamo separatamente il funzionamento di questi due moduli mod_perl.

Apache::Registry

Apache::Registry è un modulo mod_perl incluso nella distribuzione standard che simula l'ambiente CGI. Sotto Apache::Registry lo script Perl viene compilato ed eseguito e rimane disponibile in memoria per le successive invocazioni.

Ogni modifica dello script non necessita del riavvio di Apache: ad ogni richiesta, Apache::Registry controlla la data di ultima modifica per stabilire se ricompilare lo script od usare il codice compilato che ha in cache. Questo non avviene tuttavia se modifichiamo le librerie che lo script include con le istruzioni use o require: in tal caso occorre fare il restart di Apache. Una tipica configurazione di httpd.conf è la seguente:

   <IfModule mod_perl.c>
      PerlModule Apache::Registry
      Alias /perl/ /usr/local/apache/cgi-bin/
      <Location /perl>
         SetHandler perl-script
         PerlHandler Apache::Registry
         Options +ExecCGI
         PerlSendHeader On
         PerlSetupEnv On
      </Location>
   </IfModule>

Vediamo in dettaglio cosa succede. Tutte le direttive sono all'interno del blocco <IfModule>: Apache infatti processerà tutte le direttive contenute solo se è presente il modulo mod_perl (compilato staticamente o caricato dinamicamente), altrimenti ignorerà l'intero blocco.

Con PerlModule Apache::Registry precarichiamo il modulo Apache::Registry. In generale la direttiva PerlModule modulo permette di caricare (cioè compilare ed eseguire) all'avvio di Apache il modulo desiderato che sarà quindi disponibile a tutti gli script o moduli che gireranno in ambiente mod_perl.

Con la direttiva Alias associamo alla URI virtuale /perl la directory /usr/local/apache/cgi-bin dove risiedono i nostri script CGI Perl. Da notare come sia stata definita la stessa directory dove stanno in genere gli script CGI poichè con mod_perl useremo esattamente gli stessi! Con il blocco seguente <Location> definiamo le direttive mod_perl per tutte le tutte le richieste che iniziano con http://myhost.com/perl

SetHandler definisce perl-script come content handler per la directory definita all'interno di questo blocco e di fatto ne attiva il mod_perl. Vedremo successivamente cosa e un handler all'interno del ciclo di vita di Apache: per adesso accontentiamoci di sapere che il ciclo di vita di Apache (Request Loop) è composto da più fasi ad ognuna delle quali è associato un handler in corrispondenza del quale viene eseguita una porzione di codice (in genere un modulo Apache).

Con PerlHandler definiamo il modulo Apache::Registry come il gestore delle richieste per tutti i file contenuti nella directory virtuale http://myhost.com/perl. La direttiva Option +ExecCGI informa Apache che la directory contiene scripts CGI ed è richiesta dal modulo Apache::Registry. In aggiunta gli script devono essere eseguibili dall'utente Apache.

PerlSendHeader On intercetta tutte le linee di intestazione generate dallo script (ad esempio Content-type text/html) e le riconverte in un corretto header HTTP/1.x allo stesso modo in cui lo fa Apache con gli script CGI tradizionali. Questo consente di lasciare inalterati i nostri script Perl CGI senza doverci preoccupare di formattare ed inviare un corretto header HTTP. Come primo esempio vediamo il seguente e semplice script Perl, test.pl, che calcola e stampa i valori relativi al processo corrente (CPU usage, pid) e pid del processo parent.

Esempio 1. test.pl, semplice Apache::Registry script

   #!/usr/local/bin/perl
   use strict;
   use vars qw($call_count $last_invocation_time);

   print "Content-type: text/html\n\n";

   print <<EOM;
   <HEAD><TITLE>Registry/PerlRun/cgi-bin test</TITLE></HEAD>
   <BODY>
   <H1>Salve $ENV{REMOTE_ADDR}!</H1>
   <PRE>
   EOM

   my @x;
   my $time_now;
   $call_count = 0 if ! defined $call_count;
   $call_count++;
   $time_now = time();

   print "Realtime   = ", $time_now, " seconds since epoch.\n";

   if ( defined($last_invocation_time) ) {
      print "Last time  = ", $time_now - $last_invocation_time," seconds ago.\n";
   }
   $last_invocation_time = $time_now;
   @x = times(); 
   print <<EOM;
   User   CPU = $x[0]
   System CPU = $x[1]
   CallCount  = $call_count
   PID        = $$
   EOM
   print "Parent PID = ", getppid(), "\n</PRE>\n</BODY>\n<HTML>";
   exit;

Una volta riavviato Apache, non dovremo far altro che mettere lo script test.pl nella directory indicata dalla direttiva Alias e provare a lanciare l'URL http://localhost/perl/test.pl supponendo di avere browser e server sulla stessa macchina). Nel nostro caso abbiamo associato l'alias /perl alla directory /usr/local/apache/cgi-bin dove in genere risiedono gli script Perl, ma è possibile specificare qualsiasi directory. Provando ad eseguire il reload piu volte ci si rende subito conto di come lo script venga eseguito in maniera assai piu rapida che nella tradizionale chiamata CGI

Figura 2. Output dello script test.pl

Persistenza degli oggetti

Una delle caratteristiche fondamentali dell'ambiente Apache/mod_perl è che, tra successive richieste dello stesso script (o modulo), le variabili e gli oggetti dichiarati come globali sono resi persistenti.

Non vi sorprendete infatti se facendo il reload dello script test.pl l'output conterrà valori di volta in volta 'magicamente' incrementati di 1 accanto all'etichetta: 'call count' anche se nel lanciare lo script non passiamo alcun parametro e non facciamo alcun uso di tecniche di memorizzazione dello stato (tramite cookie o ID di sessione)!

Le variabili $call_count e $last_invocation_time infatti, sono state dichiarate globali con:

      use vars qw($call_count $last_invocation_time);

e al termine dell'esecuzione dello script non vengono distrutte ma rimangono inizializzate col valore dell'ultima invocazione

Questo potrebbe portare, sviluppando sotto mod_perl, ad un errato funzionamento di alcuni script che usano variabili globali non inizializzate e rappresenta uno degli errori che si fanno piu frequentemente. Al contrario, come vedremo successivamente, questo si rivela uno strumento di grande utilità quando tratteremo oggetti come le connessioni permanenti ad un database.

Potrà sembrare una banalità, ma la migliore soluzione è sempre quella di scrivere un codice pulito: l'evitare l'uso di variabili globali e l'adozione del pragma "use strict" sono un buon punto di partenza. Il pragma "use strict" viene in nostro aiuto in quanto forza l'interprete Perl, in fase di compilazione e non di esecuzione, a generare un errore ogni qualvolta vengono incontrate variabili (o più in generale oggetti) globali che non siano stati esplicitamente dichiarati con our, use vars, resi locali con my() o che non siano 'fully-qualified' (es $MyPackage::MySubClass::MyVar).

Apache::PerlRun

Apache::PerlRun e l'altro modulo mod_perl che simula l'ambiente CGI e permette una veloce esecuzione degli script Perl. A differenza di Apache::Registry, lo script Perl viene compilato ed eseguito ogni volta, e non rimane disponibile in memoria per le seguenti invocazioni. Non c'è comunque l'overhead del caricamento dell'interprete Perl per ogni script CGI. Inoltre i moduli che precarichiamo all'avvio del server sono disponibili senza dover essere ricompilati ogni volta.

Una tipica configurazione di httpd.conf è la seguente:

   <IfModule mod_perl.c>
      PerlModule Apache::PerlRun
      Alias /cgi-perl/ /usr/local/apache/cgi-bin/
      <Location /cgi-perl>
         SetHandler perl-script
         PerlHandler Apache::PerlRun
         Options +ExecCGI
         PerlSendHeader On
         PerlSetupEnv On
      </Location>
   </IfModule>

La configurazione è abbastanza simile alla precedente con la differenza che ora carichiamo il modulo Apache::PerlRun e lo definiamo come responsabile (handler) di tutti i files contenuti nella directory virtuale http://myhost.com/cgi-perl.

Ricordiamo ancora una volta che la direttiva Alias associa alla URI virtuale /cgi-perl la directory /usr/local/apache/cgi-bin dove risiedono i nostri script CGI Perl, gli stessi che utilizzavamo in CGI tradizionale. Per testare il funzionamento lanciamo l'URL http://localhost/cgi-perl/test.pl.

Subito ci si potrebbe chiedere perche utilizzare Apache::PerlRun, quando già Apache::Registry fa le stesse e cose (e anche meglio visto che mantiene in cache una copia compilata dello script pronta per l'esecuzione). Come descritto precedentemente, una delle caratteristiche fondamentali dell'ambiente Apache/mod_perl è che gli oggetti dichiarati come globali sono resi persistenti tra successive richieste. La conseguenza è che se gli script che fanno uso e dipendono da variabili globali magari non sempre inizializzate, nel tradizionale ambiente CGI funzionano senza problemi (infatti ad ogni esecuzione dello script corrisponde un diverso processo al termine del quale viene distrutto lo spazio associato al processo), cosi potrebbe non essere sotto mod_perl.

L'adozione di una 'pulita programmazione' rimane sempre la soluzione migliore, ma se volessimo subito beneficiare dell'aumento di prestazioni senza incorrere in questi problemi, il modulo Apache::PerlRun fa al caso nostro: ad ogni invocazione lo script viene caricato e compilato ma senza l'overhead del caricamento dell'interprete Perl. Abbiamo cosi tutto il tempo per 'ripulire' il codice e utilizzare successivamente Apache::Registry per incrementare ulteriormente le prestazioni e magari riscriverlo come modulo Apache (ma questo lo vedremo nelle prossime puntate).

Configurare Apache in Perl!

Concludiamo questa puntata mostrando brevemente come mod_perl ci offra la possibilità di configurare dinamicamente Apache utilizzando il Perl. È infatti possibile scrivere direttamente codice Perl in httpd.conf (o nei vari .htaccess) all'interno dell'apposita sezione <Perl></Perl>. Tutte le direttive e sezioni di httpd.conf sono disponibili e configurabili col vantaggio che è possibile aggiungervi una logica in fase di settaggio.

Come semplice esempio illustriamo una configurazione dinamica che semplifica assai la configurazione di Apache in situazioni di mass virtual hosting:

Esempio 2. Sezione di configurazione <Perl></Perl> all'interno di httpd.conf

   <Perl>
      #!perl

      $User = 'www';
      $NameVirtualHost = "192.168.1.3";
      my $base_web_dir = "/home/web";
      my @domains = qw/oltrelinux.com superpatrizio.org modperl.it/;

      foreach my $domain (@domains) { 
         push(@{$VirtualHost{$NameVirtualHost}},
            {
               ServerName => "www.$domain",
               DocumentRoot => "$base_web_dir/$domain/htdocs",
               ErrorLog => "$base_web_dir/$domain/logs/error_log",
               CustomLog => "$base_web_dir/$domain/logs/access_log common",
               ServerAdmin => "webmaster\@$domain",
               ScriptAlias => "/cgi-bin \"$base_web_dir/$domain/cgi-bin\"",
               Directory => {
                  "$base_web_dir/$domain/htdocs" =>  {
                     Options => 'Indexes FollowSymLinks',
                     AllowOverride => 'None',
                     Order => 'allow,deny',
                     Allow => 'from all'
                  },
                  "$base_web_dir/$domain/cgi-bin" => {
                     AllowOverride => 'None',
                     Options => 'None',
                     Order => 'allow,deny',
                     Allow => 'from all'
                  }
               }
            });
      }

      use Apache::PerlSections ();
      Apache::PerlSections->store("/home/web/PerlServerConfig.pm");

      __END__
   </Perl>

Subito notiamo come tutto il codice della sezione <Perl> sia nella forma:

   <Perl>
      #!perl
      ...
      __END__
   </Perl>

Questo consente di effettuare un semplice test usando direttamente l'interprete Perl a linea di comando:

   %> perl -cx httpd.conf
      httpd.conf syntax OK

dove lo switch -c effettua il controllo sintattico del codice e -x indica all'interprete di ignorare tutto il contenuto di httpd.conf prima della linea #!perl.

Le prime due linee impostano le direttive "User" e "NameVirtualHost": in generale nella sezione <Perl> per far riferimento alle corrispondenti direttive di configurazione di Apache e necessario utilizzare variabili globali il cui spelling corrisponda esattamente. Le successive linee utilizzano due variabili locali che serviranno per la configurazione dinamica di tutti i virtual host:

   my $base_web_dir = "/home/web";
   my @domains = qw/oltrelinux.com superpatrizio.org modperl.it/;

$base_web_dir contiene la directory base dove risiedono le root directory per gli host virtuali. Nell'array @domains inseriamo tutti i domini che Apache servirà come virtual host. Il successivo ciclo foreach configura dinamicamente tutte le principali direttive per i domini definiti in @domains. È opportuno soffermarsi un attimo sulla linea:

      push(@{$VirtualHost{$NameVirtualHost}}, ...

Infatti tutte le sezioni racchiuse tra TAG, come <VirtualHost> o <Directory>, vanno mappate in un hash che nel nostro caso è %VirtualHost. Per ogni elemento dell'hash si utilizza come chiave l'argomento della direttiva (l'hostname o l'IP per <VirtualHost>, la directory per <Directory>, la URI per <Location>, ecc.) e come valore un riferimento ad un hash anonimo contenente le relative direttive come coppie chiave/valore:

   $VirtualHost{'192.168.1.3'} = {
      ServerName => 'dominio.com',
      ...
   };

Nel nostro caso di virtual host name-based abbiamo il problema di avere valori dell'hash %VirtualHost con stessa chiave (l'indirizzo IP) e quindi ogni nuova entry sovrascriverebbe quella precedente. È necessario assegnare come valore di un elemento di %VirtualHost, un riferimento ad un array anonimo i cui elementi siano riferimenti ad un hash relativo ad ogni virtual host che intendiamo configurare. Più facile a vedersi che a dirsi:

   $VirtualHost{'192.168.1.3'} = [
      {
         ServerName => 'dominio-1.com',
         ...
      },
      {
         ServerName => 'dominio-2.com',
         ...
      }
   ];

Da notare che in questo esempio la directory definita in $base_web_dir deve esistere così come tutte le directories (e sub-directories) relative ai domini: ma è semplice aggiungere al codice la capacità di creare eventualmente run time la struttura (root_dominio/htdocs, root_dominio/logs, root_dominio/cgi-bin).

Tutto ciò può sembrare complesso ma se pensiamo ad una situazione di webhosting intensivo -ad esempio un centinaio di virtual host- ci accorgiamo che con sole 20 linee di codice Perl sia possibile configurare l'Apache risparmiandoci la fatica di dover scrivere e aggiornare centinaia e centinaia di linee di direttive!

Infine nelle ultime due linee:

   use Apache::PerlSections ();
   Apache::PerlSections->store("/home/web/serverconfig.pm");

viene caricato il modulo Apache::PerlSections e viene chiamato il metodo store() per eseguire uno snapshot della configurazione contenuta in tutte le sezioni <Perl> di httpd.conf e scriverlo, in sintassi Perl, su file. In genere queste istruzioni non sono necessarie ma costituiscono un valido ed ulteriore strumento di debug. Ricordo infatti che, se durante la compilazione del codice l'interprete Perl incontra un errore, Apache riporterà l'errore nell'error_log ma il server httpd non sarà avviato.

Concludiamo accennando al fatto di come sia possibile documentare la configurazione utilizzando il formato POD (Plain Old Documentation) all'interno della sezione <Perl>

Conclusione

In questa puntata abbiamo visto come sia possibile includere un interprete Perl direttamente nel processo Apache rendendo l'esecuzione degli script Perl CGI estremamente veloce ottenendo prestazioni nettamente superiori (a volte di due ordini di grandezza). Infatti uno script mod_perl rimane residente in memoria pronto per servire la successiva richiesta.

Nella prossima puntata ci spingeremo oltre, illustrando come mod_perl consenta di realizzare moduli Apache direttamente in Perl estendendo a piacimento le funzionalita del web server. A presto!

Appendice A - Principali direttive mod_perl

Ecco un elenco delle principali direttive di configurazione di mod_perl che e possibile inserire all'interno del file httpd.conf e dei file .htaccess

SetHandler handler-name

Questa direttiva non è specifica di mod_perl ma è comunque utile descriverla. SetHandler crea un'associazione tra l'handler handler-name e tutti i file delle sezioni <Directory>, <Location> o <Files> (presenti in httpd.conf o in qualche .htaccess) nelle quali viene utilizzata. Nel caso di mod_perl, l'handler si chiama perl-script.

PerlModule nome_modulo

Carica e compila il modulo nome_modulo indicato. E' l'anologo di entrambi i comandi Perl:

   use nome_modulo;
   require nome_modulo;

Il modulo viene cercato in tutti i path presenti nell'array @INC.

PerlRequire script_file

Carica e compila ed esegue lo script indicato. E' l'anologo del comando Perl:

   require 'script_file';

A differenza di PerlModule, è necessario indicare un path assoluto o relativo. In caso di path relativo, lo script viene cercato utilizzando i path presenti nell'array @INC.

Perl*Handler nome_modulo

Le direttive Perl*Handler sono una serie di direttive che associano un determinato handler della Request Loop di Apache ad un modulo Perl. Vengono usate per installare i moduli Apache scritti in Perl in fase di avvio e/o run time.

PerlSendHeader {On|Off}

Intercetta tutte le linee di intestazione generate dallo script (ad esempio Content-type text/html) e le riconverte in un corretto header HTTP/1.x allo stesso modo in cui lo fa Apache con gli script CGI tradizionali. Questo consente di lasciare inalterati i nostri script Perl CGI senza doverci preoccupare di formattare ed inviare un corretto header HTTP.

PerlSetEnv nome valore

Consente il settaggio di una variabile di ambiente disponibile all'interno dello script CGI.

PerlSetupEnv {On|Off}

Imposta e passa tutte le variabili di ambiente tradizionali (cioè tutte le variabili HTTP_REFERER, REQUEST_URI, ecc.) agli script CGI.

PerlPassEnv env_var

Consente di passare la variabile di ambiente env_var agli script CGI

PerlFreshRestart {On|Off}

Consente il refresh (caricamento e ricompilazione) di tutti i moduli precedentemente caricati con il solo restart del server. Altrimenti è necessario stoppare e riavviare il server affinché le modifiche ai moduli mod_perl abbiano effetto.

PerlWarn {On|Off}

Consente di abilitare i warnings per tutto il codice Perl dei moduli mod_perl

PertTaintCheck {On|Off}

Consente di attivare il taint check per tutto il codice Perl gestito da mod_perl

PerlSetVar name value

Consente di passare informazioni dal file di configurazione di Apache al moduli mod_perl. Ad esempio:

   PerlSetVar base_dir /usr/local/my_dir

Il valore contenuto in base_dir è poi recuperabile all'interno del modulo tramite chiamate ad opportuni metodi.

Bibliografia

mod_perl

• Writing Apache Modules With Perl and C, di Lincoln Stein e Doug MacEachern (O'Reilly & Associates, 1999, ISBN 156592567X)
• mod_perl Guide, di Stas Bekman (http://perl.apache.org/guide)

Perl

• Programming Perl, 3rd Edition, di Larry Wall, Tom Christiansen e Jon Orwant (O'Reilly & Associates, 2000, ISBN 0596000278)
• Perl Cookbook, di Tom Christiansen e Nathan Torkington (O'Reilly & Associates, 1998, ISBN 1565922433)

Apache

• Apache the Definitive Guide, di Ben Laurie e Peter Laurie (O'Reilly & Associates, 1999, ISBN 1565925289)

Risorse

mod_perl

• http://perl.apache.org - Sito ufficiale del progetto Apache/mod_perl
• http://www.modperl.com - Sito ufficiale del libro Writing Apache Modules With Perl and C
• modperl-subscribe@apache.org - Mailing list ufficiale mod_perl

Perl

• http://www.perl.com - Sito ufficiale del Perl
• http://www.cpan.org - Sito del CPAN, acronimo di Comprensive Perl Archive Network, un immenso repository di librerie e moduli (ma non solo) sviluppati dalla comunità Perl/mod_perl, una risorsa che probabilmente non ha eguali in altri linguaggi di programmazione (vedere Linux & C. n 18).

Apache

• http://www.apache.org - Sito ufficiale dell'Apache Software Foundation
• http://httpd.apache.org - Sito ufficiale del progetto web server httpd Apache

Convenzioni usate in questo articolo

Le seguenti convenzioni tipografiche sono stato utilizzate in questo articolo:

Corsivo

Utilizzato nelle URL, nei percorsi di file, nelle pagine di manuale, nei titoli di libri e/o articoli. Anche nuovi termini cui si intende dare particolare rilievo sono formattati in corsivo.

Larghezza costante

Utilizzato negli esempi di codice e file di configurazione, nel codice che appare all'interno del testo e negli esempi che illustrano cosa digitare a linea di comando.

Negli articoli ci sono molti esempi di codice Perl: alcuni sono solamente pezzi di codice, altri invece programmi completi che possono essere individuati poiché iniziano tutti con la linea #! (shebang):

   #!/usr/bin/perl

Tutti gli esempi che illustrano procedure a linea di comando usano %> per indicare il generico prompt della shell:

   %> perl -e 'print "Hello world\n"'
      Hello word

Occasionalmente viene utilizzato #> per indicare espressamente la shell dell'utente root:

   #> perl -e 'print "Hello world\n"'
      Hello word