Guida Apache 1. Introduzione: i Web Server 2. Installare Apache su

Guida Apache
1. Introduzione: i Web Server
2. Installare Apache su Linux
3. Installare Apache su Windows
4. Operazioni base di Apache: avvio, riavvio e arresto
5. httpd.conf: il cuore di Apache
6. Configurare Apache: httpd.conf - 1a parte
7. Configurare Apache: httpd.conf - 2a parte
8. Agire sulle risorse: direttive di Apache
9. Gestione dinamica e metodi di controllo
10. Autenticazione in Apache
11. I filtri di Apache
12. Creazione dell'Index e gestione delle directory di Apache
13. Domini virtuali di Apache
14. Errori su Apache e la loro gestione
15. Opzioni avanzate di Apache: alias e redirect
Introduzione: i Web Server
Come funziona Internet? Una semplice domanda la cui risposta svela spesso dinamiche complesse. Il comune fruitore
della Rete non ha bisogno di conoscere le meccaniche che regolano il funzionamento del Web, un browser per la
navigazione con il quale accedere alle risorse desiderate gli è più che sufficiente.
Lo stesso discorso non può essere applicato a coloro che vogliono fare della creazione e della gestione di pagine web il
loro mestiere, per essi è necessario conoscere quali meccanismi entrano in gioco durante la normale attività di
navigazione che milioni di persone mettono in atto ogni giorno.
Cerchiamo allora di rispondere alla nostra domanda iniziale: come funziona Internet?
Il Web si basa sul principio del trasferimento di informazioni da un terminale (Host) all'altro attraverso dei sistemi di
trasmissione detti protocolli, tra questi HTTP (Hyper text Transfer Protocol) è quello più diffuso. Questo protocollo
prevede che l'utente navigatore digitando una URL o cliccando su un link richieda l'accesso a determinate risorse
(input); queste risorse, quando disponibili, gli vengono inviate sotto forma di file, generalmente pagine html o immagini
(output).
In pratica l'utente grazie al meccanismo delle URL e dei link, non fa altro che indicare attraverso il programma di
navigazione (browser) del suo computer (client), il percorso da seguire per raggiungere determinate informazioni
contenute in un altro computer (server). Un server è quindi un elaboratore che contiene e fornisce file.
Nel caso specifico dei server Web si parla di computer destinati ad ospitare siti internet, questi ultimi possono essere
composti da pagine statiche (semplici pagine .htm e html) o dinamiche (.php, asp..), una distinzione molto importante
per l'argomento che andremo a trattare in questa guida: il Web server Apache.
Un Web server non è altro che un software installato in un server con la funzione di elaborare pagine web e generare
dinamicamente contenuti.
Le semplici pagine .htm non necessitano di particolari interventi da parte del Web server, il loro codice viene
interpretato dal browser del computer client e per questo l'html è definito come un linguaggio client side. Le pagine
.php o .asp, contengono dei codici destinati a produrre dei comportamenti e a generare dinamicamente html, perchè ciò
sia possibile è necessaria la mediazione di un Web server; PHP e ASP vengono quindi definiti linguaggi server side.
Esemplificando, quando si invia ad un Web server la richiesta di una pagina .htm, statica, esso:
1.
2.
3.
riconosce la richiesta
cerca e, se presente, trova la pagina nel computer server
invia la pagina al browser.
Nel caso di una pagina dinamica, invece, il Web server:
1.
2.
3.
4.
riconosce la richiesta
cerca e trova la pagina all'interno del server Web
esegue le istruzioni contenute all'interno del codice producendo dinamicamente contenuti
invia la pagina browser.
La differenza salta immediatamente agl'occhi.
Nei prossimi capitoli ci occuperemo appunto dell'installazione, della configurazione, della gestione e delle
caratteristiche peculiari di Apache, il Web server più utilizzato della rete.
Installare Apache su Linux
Il Web server Apache è un software Open Source, questo vuol dire che il suo codice è pubblicamente disponibile ed
aperto al contributo di chiunque desideri modificarlo agevolando così il suo continuo sviluppo; in questo modo Apache
ha potuto usufruire dell'opera volontaria di migliaia di programmatori sparsi in tutto il mondo.
Inoltre, Apache è un programma scaricabile gratuitamente e liberamente dalla Rete (http://httpd.apache.org/), elemento
che insieme alle sue indubbie qualità di stabilità e potenza ha contribuito non poco alla grande diffusione di questo Web
Server.
Apache lavora agevolmente sia in ambiente Linux che Windows, dunque in questo e nel prossimo capitolo della Guida
descriveremo le procedure necessarie all'installazione in entrambi i Sistemi Operativi.
Esistono vari modi per installare Apache in ambiente Linux: possiamo utilizzare i CD d'installazione della nostra
distribuzione; possiamo usare il sistema RPM (RedHat Package Manager); infine, possiamo utilizzare il metodo
classico basato sulla compilazione dei sorgenti.
Se disponiamo dei CD d'installazione di una distribuzione Linux, come per esempio la Mandrake (da un pò di tempo
ribattezzata con il nome di Mandriva), potremo integrare Apache nel nostro sistema utilizzando il comodo Rpmdrake,
un software con cui gestire le installazioni, le disinstallazioni e l'aggiornamento dei pacchetti presenti nell'OS. Da Kde
andremo su:
Configurazione > Gestione pacchetti
A questo punto avremo a disposizione una comoda interfaccia grafica dotata di un motore di ricerca; cerchiamo la voce
Apache è dal database verranno estratti i risultati relativi al programma che stiamo cercando; una volta selezionato il
quadratino bianco posto alla destra del suo nome e cliccato su installa, Rpmdrake controllerà la presenza nel sistema
delle necessarie dipendenze e ci richiederà il CD d'installazione in cui Apache è contenuto. Non dovremo fare altro che
inserire il CD nel lettore e rimpiazzarlo con un altro se e quando ci verrà chiesto, in pochi attimi avremo un Web server
Apache installato su Linux.
Oltre all'uso di Rpmdrake, abbiamo l'alternativa di poter installare manualmente l'RPM di Apache dopo averlo
scaricato dalla rete (per esempio da questo link). Una volta terminato il download di una delle versioni disponibili (ad
esempio la apache-1.3.31-40.i386.rpm), dovremo digitare da Shell la seguente riga di comando:
rpm -ihv ./apache-1.3.31-40.i386.rpm
Tanto basterà ad installare Apache. Il nostro sistema verrà però integrato da un Web server "essenziale" a cui dovremo
aggiungere man mano i "moduli", di cui avremo bisogno come quello per PHP, SSL, PERL e molti altri.
L'ultimo sistema di installazione di cui parleremo, è quello classico in ambiente Linux effettuato per compilazione di
sorgenti. Nonostante la nomea di procedura ostica che si porta dietro, questo metodo non presenta particolari difficoltà.
Quello che dovremo fare sarà scaricare dalla rete un archivio compresso contenente i sorgenti di Apache (per esempio
l'archivio apache_1.3.33.tar.gz da questo link).
A questo punto dovremo scompattare e decomprimere l'archivio attraverso il comando:
tar xvfz apache_1.3.23.tar.gz
Raggiungeremo quindi i sorgenti con il comando:
cd apache_1.3.23
e cominceremo la compilazione digitando:
./configure --prefix=/usr/local/apache
dove "prefix" indicherà il percorso verso la directory d'installazione. Per terminare la compilazione useremo il
comando:
make
e finiremo quindi l'installazione con un:
make install
A questo punto potremo controllare se tutto è andato bene lanciando da Shell l'istruzione:
/usr/local/apache/bin/apachectl start
Se non riceveremo messaggi di errore facciamoci pure i complimenti, l'installazione di Apache sarà avvenuta con
successo!
Installare Apache su Windows
Notoriamente Linux rappresenta l'ambiente di sviluppo e di produzione privilegiato per Apache. La sterminata
comunità di sviluppatori che ruota intorno a questo Web server ha comunque prodotto una buona integrazione anche
per Windows; quindi coloro che non hanno pratica del Pinguino potranno in ogni caso testare le funzionalità di Apache
nel loro PC dotato di OS Microsoft.
Il sito ufficiale di Apache mette a disposizione dei comodi pacchetti .exe comprendenti una facile installazione guidata
non dissimile da quella utilizzata per la maggior parte degli applicativi esistenti.
I download disponibili sono numerosi e ruotano principalmente attorno alle due versioni principali di Apache, la 1.3.x e
la 2.x; dato che la prima è indubbiamente la più testata e meno afflitta da bugs (soprattutto per quanto riguarda
Windows), sarà questa che utilizzeremo negli esempi del presente capitolo.
Una volta scaricato il pacchetto di installazione di una versione di Apache, per esempio la "1.3.31-win32-x86no_src.exe", sarà sufficiente un doppio click sul file di Setup e la procedura guidata avrà inizio.
Dopo aver visualizzato il classico messaggio di benvenuto cliccheremo su [Next]; accetteremo i termini di utilizzo del
programma, leggeremo le note su questa versione e poi cliccheremo ancora su [Next].
Appariranno tre campi form da compilare:
1.
2.
3.
Network Domain: sarà sufficiente scrivere "localhost" se stiamo operando su un PC che non fa parte di una
rete intranet; in caso contrario dovremo inserire il nome del dominio di riferimento.
Server Name: inseriamo un nome a piacere per il nostro server; nel caso in cui operiamo in una rete dovremo
invece indicare il nome della nostra postazione all'interno della stessa.
Administrator's E-mail Address: inserite un indirizzo e-mail.
Per terminare questa fase selezioniamo l'opzione per avviare Apache come un servizio disponibile per tutti gli utenti e
clicchiamo su [Next]:
A questo punto ci verrà chiesto di selezionare la tipologia di installazione: scegliamo quella completa e andiamo avanti.
Ora dovremo indicare la directory d'installazione; se non abbiamo particolari preferenze in merito lasciamo invariata
quella di default e clicchiamo su [Next] poi su [Install] e [Finish].
Dato che Apache potrà partire automaticamente a fine installazione, per controllare se tutto è andato per il meglio
lanceremo il nostro browser e digiteremo l'URL:
http://localhost/
oppure:
http://127.0.0.1/
Il messaggio di benvenuto di Apache sarà:
Funziona!
Il Server Web Apache è stato installato su questo sito Web!
Operazioni base di Apache: avvio, riavvio e arresto
Descrivere le semplici operazioni relative all'avvio, al riavvio e all'arresto di Apache, rappresenta un'utile occasione per
approfondire il discorso riguardante il funzionamento di questo Web server.
Innanzitutto, come funziona Apache? In pratica, al suo avvio esso genera un processo principale, noto come httpd, a
cui si accompagnano tutta una serie di processi subordinati ognuno destinato ad una particolare funzione e tutti "in
ascolto" (listening), pronti ad entrare in gioco nel caso sia necessario il loro intervento. I processi di Apache attendono
gli input provenienti dai client attraverso una "porta", in genere la n°80; questo parametro può però essere modificato
rimanendo nell'ambito delle prime 1024 porte.
Nel momento del riavvio vengono arrestati tutti i processi secondari, rimane invece in vita httpd che si occuperà di
rigenerare gli altri processi seguendo le indicazioni del file di configurazione (httpd.conf).
Quando invece, richiediamo ad Apache di arrestarsi il processo principale si spegnerà e causerà la "morte" di tutti i
processi secondari.
In Linux abbiamo la possibilità di avviare Apache e i suoi processi attraverso due comandi principali:
"/etc/rc.d/init.d/httpd"
e
apachectl
entrambi devono essere corredati dalle eventuali opzioni o argomenti: "start, "restart" e "stop".
Così, nel caso di "/etc/rc.d/init.d/httpd" per avviare Apache digiteremo:
/etc/rc.d/init.d/httpd start
Per riavviare Apache avremo poi:
/etc/rc.d/init.d/httpd restart
Infine, per arrestare Apache utilizzeremo:
/etc/rc.d/init.d/httpd stop
Stesso discorso per quanto riguarda "apachectl":
apachectl start
avvierà Apache. Il comando:
apachectl restart
riavvierà il Web server e:
apachectl stop
provvederà ad arrestarlo.
Per quanto riguarda le medesime operazioni in ambiente Windows, non sarà necessario inoltrarci in descrizioni
approfondite, ci limiteremo ad indicare le semplicissime procedure per l'avvio, il riavvio e l'arresto di Apache che il
lettore potrà eseguire con pochi click del mouse:
Start / Programmi / Apache HTTP Server / Control Apache Server / Start
Start / Programmi / Apache HTTP Server / Control Apache Server / Restart
Start / Programmi / Apache HTTP Server / Control Apache Server / Stop
httpd.conf: il cuore di Apache
I comportamenti e le funzionalità di Apache vengono stabilite da un file di configurazione chiamato httpd.conf
modificabile attraverso un semplice editor di testo come Vim o Gedit per Linux e NotePad per Windows.
Se non ricordate la directory in cui avete installato Apache in Linux, generalmente:
/usr/local/apache/conf/
potrete facilmente accedere al percorso del file di configurazione digitando da Shell la riga di comando:
locate httpd.conf
Per quanto riguarda Windows, la directory di default è in genere:
C:\Programmi\Apache Group\Apache\conf
In alternativa basterà un semplice:
Start / Trova / File e Cartelle / httpd.conf
Editando httpd.conf troverete una lunga serie di istruzioni; alcune righe saranno precedute dal simbolo del cancelletto
"#", ciò significa che sono state "commentate" e le istruzioni che contengono non avranno influenza sul funzionamento
di Apache; in molti casi si tratta di semplici indicazioni riguardanti le diverse tipologie di configurazione.
Le righe non precedute da "#" sono invece vere e proprie istruzioni di configurazione abilitate; prendiamo per esempio
le righe:
#AddModule mod_rewrite.c
AddModule mod_access.c
Il cancelletto davanti ad "AddModule mod_rewrite.c" indica che questo modulo non è abilitato e non lo sarà fino a
quando questa riga non verrà "decommentata" eliminando il "#"; al contrario "AddModule mod_access.c" indica un
modulo abilitato che potrà essere disabilitato inserendo il cancelletto a inizio riga.
Come potrete notare httpd.conf è un file lungo e ricco di opzioni, non sarà possibile descriverle tutte in un unico
capitolo, dedicheremo quindi i prossimi due a sottolineare nel miglior modo possibile le sue funzionalità principali.
Configurare Apache: httpd.conf - 1a parte
La prima sezione del file httpd.conf, ("Section 1"), è dedicata all'ambiente in cui opera Apache ("Global
Environment").
All'interno di essa troviamo alcune istruzioni fondamentali come il ServerType, attraverso cui viene indicata la
modalità di funzionamento di Apache; nel nostro caso quest'ultima sarà: ServerType standalone, che consente di
mantenere il Web server sempre attivo limitando i tempi di latenza. In pratica la modalità standalone permette ad
Apache di lavorare come servizio in background ("demone") rispondendo autonomamente agli input provenienti dai
client.
Abbiamo poi la ServerRoot, che stabilisce la directory in cui si trovano i file di configurazione e gli altri file necessari
per il funzionamento di Apache.
Di seguito troviamo il PidFile, il cui percorso su Linux è in genere:
/var/run/httpd.pid
mentre in Windows sarà di solito in:
logs/httpd.pid
httpd.pid è in pratica il file in cui Apache scrive i processi in atto al momento del suo avvio.
Continuando a scorrere la Section 1, troveremo altre due opzioni: ResourceConfig e AccessConfig, rispettivamente
correlate ai file "srm.conf" e "access.conf". Questi ultimi dovrebbero essere letti dal Web server una volta terminata la
lettura di httpd.conf; in realtà nelle ultime versioni tali istruzioni sono ormai obsolete e le funzioni dei due file sono
state incorporate da httpd.conf. Ne consegue che le opzioni ResourceConfig e AccessConfig appariranno commentate
in Windows e settate su "/dev/null" in Linux.
Andando oltre visualizzeremo l'istruzione Timeout dalla funzione abbastanza intuitiva: quando il tempo di attesa per la
soddisfazione dell'input inviato da un client supera il valore impostato espresso in secondi, allora viene inviato un
messaggio d'errore. Di default il time out scatta dopo 300 secondi, ma può essere modificato a piacere soprattutto per
limitare i problemi generati dal "traffico" sul proprio server Web.
Dopo Timeout abbiamo l'istruzione KeepAlive che può essere completata tramite le opzioni "On" ed "Off". Se settata
in "On", KeepAlive permetterà di inviare più file attraverso una stessa connessione TCP. In caso contrario
(sconsigliato), "Off" aprirà una nuova connessione ad ogni richiesta.
A KeepAlive segue l'istruzione MaxKeepAliveRequests, grazie alla quale potremo indicare un valore (di default 100)
corrispondente alla quantità di richieste possibili per singola connessione TCP.
KeepAliveTimeout, di default impostato a 15, esprime in secondi il tempo che il Web Server dovrà aspettare per
accogliere un'ulteriore richiesta prima che la connessione venga chiusa.
Sottolineiamo poi MaxRequestsPerChild: se httpd, il processo principale di Apache, è "padre", allora i suoi processi
secondari saranno "figli". Grazie a questo parametro è possibile settare la quantità di richieste gestibili da ciascun
processo subordinato; se indichiamo "0" (infinito), ogni processo figlio avrà la possibilità di gestire illimitate richieste.
Consigliamo in ogni caso di specificare comunque un valore (anche in miliardi) in modo da evitare eccessivi
sovraccarichi.
Segnaliamo infine il supporto per i DSO (Dynamic Shared Object). Questa voce si divide in due parti: "LoadModule" e
"AddModule". Osservando queste istruzioni troveremo una serie di righe, molte delle quali commentate, che
permettono di abilitare o disabilitare alcuni "moduli" o funzionalità addizionali. Quando viene decommentata, aggiunta
o commentata una voce in "LoadModule" è necessario operare nello stesso modo sull'"AddModule" corrispondente.
Se per esempio decidiamo di installare PHP 5 come modulo aggiuntivo di Apache, per rendere operativa questa
modifica dovremo aggiungere in corrispondenza dei "LoadModule" la riga non commentata
LoadModule php5_module "PATH/php/php5apache.dll"
e, in corrispondenza degli "AddModule", dovremo fare lo stesso scrivendo
AddModule mod_php5.c
Configurare Apache: httpd.conf - 2a parte
Passiamo ora all'analisi delle istruzioni più importanti riportate nella "Section 2" del file di configurazione di Apache
httpd.conf; come vedremo, questa sezione contiene voci correlate alla configurazione del Web server ("'Main' server
configuration").
Innanzitutto troviamo il riferimento alla porta di "ascolto" dei processi di Apache, di default la Port 80. Come abbiamo
già avuto modo di sottolineare, è possibile modificare il numero di questa porta TCP rimanendo nell'ambito delle prime
1024 porte. Se per esempio nel nostro computer è installato un altro Web server che attende le richieste sulla porta 80,
come IIS della Microsoft, potremo modificare quella di default di Apache in 81.
Andando oltre, troveremo altre opzioni sulle quali è possibile intervenire. Tra queste abbiamo l'indirizzo di posta del
ServerAdmin che, se ciò non è già stato fatto in installazione, può essere modificato inserendo la nostra mail personale
o di lavoro.
Il ServerName, cioè il nome della nostra macchina server, varia a seconda del dominio di appartenenza; se lavoriamo
in locale e al di fuori di una rete potremo lasciare senza problemi la consueta dicitura "localhost".
La DocumentRoot, stà ha indicare il percorso che porta alla cartella in cui sono contenute le pagine del nostro sito
Web. Questo parametro può essere variato a seconda delle nostre esigenze; generalmente avremo in Linux qualcosa
come:
"/var/www/html"
mentre in Windows troveremo:
"C:/Programmi/Apache Group/Apache/htdocs"
Leggeremo poi una serie di voci di questo tipo:
<Directory "PATH_per_la_ROOT">
Options Indexes FollowSymLinks Includes
AllowOverride All
Order allow,deny
Allow from all
</Directory>
in esse viene impostata una directory recante direttive (container) per la configurazione del server. Delle direttive
parleremo più approfonditamente tra poco. Andando avanti troveremo:
<IfModule mod_mime.c>
TypesConfig /PATH/mime.types
</IfModule>
Un'istruzione, quella appena proposta, con la quale viene indicato che, nel caso (if) in cui sia abilitato il "modulo per i
MIME" ("mod_mime"), dovrà essere caricato il file/elenco con la lista dei MIME file type ("mime.types").
Ora passiamo a DefaultType, solitamente predefinito come "text/plain", che stabilisce la tipologia di file forniti da
Apache.
Un'altra istruzione importante è ErrorLog, per la quale viene stabilito il percorso che dovrà portare ai "log" in cui
verranno scritti gli errori conseguenti alle richieste non soddisfatte ("error_log"). Ad ErrorLog si accompagna
un'opzione relativa al livello di debugging generalmente settata in "warn", un valore medio in una scala crescente che
conta: "debug", "info", "notice", "warn", "error", "crit", "alert", "emerg".
Sono poi degni di nota i riferimenti alla direttiva Alias e al relativo "modulo"; di questa direttiva parleremo più avanti,
per ora specificheremo il fatto che grazie a queste istruzioni è possibile definire un alias (URL "traslata") per una
cartella destinata ad ospitare script CGI posizionata esternamente rispetto alla DocumentRoot e quindi non accessibile
dal web.
Andando oltre troveremo alcune delle istruzioni più note dei Web Server, gli ErrorDocument 500, 404 e 403.
L'errore 500, conosciuto anche come "Internal server error" viene notificato nel caso in cui una condizione inaspettata
(un errore interno al programma che gestisce il servizio) impedisca al server di soddisfare una richiesta del client.
L'errore 404, il notissimo "File Not Found", viene notificato quando il Web server non trova l'informazione richiesta.
Le cause di questa notifica sono in genere due: un errore nella sintassi dell'URL o l'inesistenza della risorsa desiderata
all'interno del percorso indicato.
L'errore 403, conosciuto anche come "accesso negato" ("Unauthorized user"), si verifica quando l'utente prova ad
accedere ad una pagina "protetta" senza averne l'autorizzazione.
I messaggi di notifica degli ErrorDocument sono personalizzabili e possono consistere in un'informazione da inviare
al client:
ErrorDocument 500 "The server made a boo boo
O in una pagina da visualizzare in alternativa a quella richiesta:
ErrorDocument 404 /missing.html
Terminiamo il nostro discorso riguardante le impostazioni di httpd.conf segnalando l'istruzione relativa al
"mod_setenvif":
<IfModule mod_setenvif.c>
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;"
nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
rowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
</IfModule>
In essa vengono settate differenti opzioni per le risposte da inviare alle particolari richieste che possono pervenire da
specifiche tipologie di browser.
Agire sulle risorse: direttive di Apache
Alla base del funzionamento di Apache abbiamo le direttive, note anche come container. I container raggruppano
risorse e informazioni con direttive di configurazione comuni; in pratica, i file e le cartelle di uno stesso gruppo
rispondono alle medesime regole. Per isolare un gruppo dagli altri e rendere valide soltanto per esso determinate
direttive basterà utilizzare una sintassi simile a quella HTML:
<Directory /PATH/file o cartella>
istruzione
istruzione
………….
</Directory>
Abbiamo visto un esempio di container nel capitolo precedente:
<Directory "PATH_per_la_ROOT">
Options Indexes FollowSymLinks Includes
AllowOverride All
Order allow,deny
Allow from all
</Directory>
Come si avrà modo di osservare, le direttive vengono imposte attraverso semplici parole inglesi come Allow (permetti)
o deny (nega).
All'interno di httpd.conf, troveremo sovente alcune indicazioni che costituiscono la sintassi base delle direttive.
Innanzitutto osserviamo i "tags" minore "<" e "maggiore" ">" con i quali viene delimitata la directory per cui le
direttive avranno valore. Per ogni directory viene indicato il relativo percorso e le direttive influiranno sia sulla cartella
principale che sul suo contenuto in termini di file e sotto cartelle.
Grazie all'uso delle "espressioni regolari", è possibile indicare le cosiddette DirectoryMatch in modo da imporre
determinate direttive soltanto ad alcune cartelle, come ad esempio quelle che cominciano con una determinata lettera
dell'alfabeto.
Oltre a <Directory..></Directory> e DirectoryMatch, avremo la possibilità di impostare direttive anche attraverso
Files e FilesMatch, magari utilizzando il comodo carattere jolly "*" (tutto); se per esempio scriviamo:
Files *.ext
la nostra direttiva avrà valore per tutti (*) i file dotati di una determinata estensione indipendentemente dal loro nome.
Location e LocationMatch funzionano similmente alle istruzioni precedenti, ma non si riferiscono a dei percorsi
interni al server, bensì a delle URL specifiche. In httpd.conf troviamo per esempio questa direttiva:
<pre><Location /server-status>
SetHandler server-status
Order deny,allow
Deny from all
Allow from NOME_DOMINIO
</Location>
Che autorizza la ricezione dei "reports" del server all'indirizzo "http://servername/server-status".
Abbiamo poi VirtualHost utilizzato per le istruzioni relative alla gestione dei "domini virtuali" con più siti internet di
cui parleremo a breve; per ora basti sapere che tramite VirtualHost è possibile settare diverse DocumentRoot, indirizzi
di posta elettronica dell'Administrator, percorsi verso i file di "log" e molto altro.
Infine, è possibile utilizzare le istruzioni Limit e LimitExcept per differenziare i criteri di accesso a file e cartelle; se
Limit stà appunto per "poni un limite a", LimitExcept svolge una funzione più specifica, significa infatti "poni un
limite a tutti i metodi di accesso tranne che a quello indicato". Raramente queste due istruzioni sono espresse da sole e
più frequentemente sono parte integrante di una direttiva principale. Prendendo spunto da httpd.conf, proponiamo un
esempio che riguarda il controllo degli accessi alle directory dello User:
<Directory "PATH">
AllowOverride FileInfo AuthConfig Limit
Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
<Limit GET POST OPTIONS PROPFIND>
Order allow,denyAllow from all
</Limit>
<LimitExcept GET POST OPTIONS PROPFIND>
Order deny,allow
Deny from all
</LimitExcept>
</Directory>
Gestione dinamica e metodi di controllo
Come abbiamo avuto modo di osservare, Apache risponde a decine di direttive che stabiliscono i diversi
comportamenti del Web server. Dato che sarebbe abbastanza scomodo dove indicare una particolare direttiva e
modificare il file di configurazione ogni volta che si presentano determinate fattispecie, caso che per esempio si verifica
per l'introduzione di un nuovo "modulo", httpd.conf possiede alcune istruzioni grazie alle quali è in grado di gestire
dinamicamente diverse situazioni a seconda dei casi e delle necessità.
Riguardiamo un esempio già visto in precedenza:
<IfModule mod_setenvif.c>
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch "MSIE 4\.0b2;"
nokeepalive downgrade-1.0 force-response-1.0
BrowserMatch "RealPlayer 4\.0" force-response-1.0
rowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0
</IfModule>
Grazie al "mod_setenvif.c" è possibile stabilire le differenti risposte da inviare alle richieste che possono provenire da
specifiche tipologie di browser.
Alla base di tutto abbiamo il costrutto di controllo IfModule che permette di dar luogo alle istruzioni indicate nella
direttiva sole se (if) il "modulo" è presente ed abilitato; in caso contrario non avremo la necessità di intervenire su
httpd.conf in quanto questa possibilità è già prevista da IfModule.
Oltre ad IfModule, abbiamo IfDefine che per quanto riguarda la sua funzione non si differenzia molto dal primo ma
entra in gioco soltanto in casi specifici come per esempio test del Web server e debugging; quando il sistema è in
queste fasi, IfDefine consente l'esecuzione di determinate direttive che ne rendono più semplice l'esecuzione.
Se IfModule e IfDefine gestiscono risorse interne, Include permette di richiamare file di configurazione esterni alla
DocumentRoot anche se questi sono indicati all'interno di direttive che richiamano risorse ad essa interne; in Linux
per esempio abbiamo:
Include /etc/httpd/conf.d
un istruzione che richiama all'interno di una direttiva le risorse relative al percorso specificato.
Per quanto riguarda i metodi di controllo, Apache viene regolato in particolare da due istruzioni chiamate Options e
Overrides.
La prima direttiva, Options, configura i rapporti tra il Web server e il sistema in cui esso è installato. Avremo quindi
nove reazioni diverse (opzioni) di Apache a seconda degli stimoli provenienti dal File System:
1.
2.
3.
4.
5.
6.
7.
8.
9.
All: è una "Global Option", ciò vuol dire che viene settata di default; essa ha la funzione di abilitare
l'esecuzione delle funzionalità a cui è riferita.
None: è anch'essa una "Global Option", disabilita l'esecuzione delle funzionalità a cui è riferita; può comunque
essere modificata accertandosi prima che gli interventi da effettuare non pregiudichino la sicurezza del sistema.
FollowSymLinks: abilita i percorsi indicati dai "link simbolici" che richiamano PATH realmente esistenti nel
server.
SymLinksIfOwnerMatch: svolge la stessa funzione di FollowSymLinks ma solo se il proprietario coincide
Includes: rende possibile l'esecuzione di scripts lato server.
IncludesNOEXEC: svolge la stessa funzione di Includes ma impedisce l'esecuzione di comandi locali.
MultiViews: permette la "Content Negotiation"; contrariamente a quanto viene spesso detto riguardo a
MultiViews, essa non elimina le estensioni dei file, più semplicemente crea molteplici rappresentazioni di una
stessa risorsa web, si pensi per esempio ai siti internet "multilingua". Soltanto nel caso di MultiViews le
"Global Option" All e None non sono settate di default.
Indexes: nel caso in cui non esista una pagina "index" (pagina d'"ingresso" del sito internet), permetterà di
visualizzare l'elenco delle risorse interne alla directory indicata.
ExecCGI: permette l'esecuzione dei CGI ed è necessaria per qualsiasi eseguibile.
Per quanto riguarda Overrides, dobbiamo sottolineare la funzione svolta dalla direttiva AllowOverride con la quale si
definiscono le funzionalità che non verranno abilitate o limitate dai noti file ".htaccess"; questi ultimi sono dei file che
opzionalmente possono essere usati per definire delle configurazioni specifiche riferite alle directory in cui vengono
creati.
Nel caso di AllowOverride, abbiano a disposizione sette opzioni per la configurazione:
1.
2.
3.
4.
5.
6.
7.
All: autorizza il non rispetto delle direttive.
None: impedisce il non rispetto delle direttive.
AuthConfig: consente l'impiego di direttive di autorizzazione.
FileInfo: consente l'impiego di direttive per il controllo delle tipologie di documenti.
Indexes: consente l'impiego di direttive per il controllo della visualizzazione dell'elenco delle directory.
Limit: consente l'impiego di direttive per il controllo degli accessi.
Options: consente l'impiego della direttiva Options
Per chiarire le idee proponiamo un piccolo esempio:
<Directory /PATH/html>
Options Indexes
AllowOverride All
</Directory>
Come è facile osservare, il codice appena proposto rende possibile visualizzare l'elenco dei contenuti interni alla
DocumentRoot, ed è inoltre consentito ignorare le direttive espresse tramite un file ".htaccess".
In ogni caso, per questioni di sicurezza o di ottimizzazione del sistema sarà sempre possibile disabilitare gli ".htaccess"
tramite il metodo AllowOverride utilizzando un semplice script da inserire in httpd.conf:
<Directory />
AllowOverride None
</Directory>
questo script avrà efficacia per tutte le directory a parte quelle in cui saremo noi ad autorizzare l'Override.
Autenticazione in Apache
Le direttive del Web server Apache possono tornarci utili per stabilire metodi di autorizzazione per l'accesso alla
DocumentRoot utilizzando la classica procedura basata su un nome utente (user name) e su una parola chiave
(password).
Sarà possibile cifrare i dati di accesso inserendoli in un apposito file chiamato htpasswd con l'unica condizione che il
nome utente e la parola chiave siano differenti da quelli già indicati per l'accesso al sistema in cui Apache è stato
installato.
Oltre ai dati di accesso, è possibile stabilire dei gruppi, ognuno facente capo ad un unico nome; la metodologia "per
gruppi" permetterà di stabilire regole d'accesso valide per tutti gli utenti appartenenti ad essi. Otterremo questo risultato
semplicemente agendo sulla direttiva AuthName a cui passeremo come parametro il nome necessario
all'autorizzazione.
Tramite AuthName, è possibile descrivere all'utente il tipo di autorizzazione richiesta in modo che egli sia sempre in
grado di utilizzare la procedura corretta a seconda dei casi.
Un'altra direttiva fondamentale è AuthType, riferita alla tipologia di autenticazione; in ogni caso per Apache
quest'ultima dovrà essere settata come Basic o come Digest. Nel caso di Basic, l'autenticazione consisterà in un
semplice invio dei dati inseriti dall'utente, con Digest, invece, nome utente e password verranno criptati utilizzando il
sistema di codifica MD5; quest'ultimo metodo, in linea teorica preferibile, è purtroppo al momento non ben supportato.
Ad AuthType segue AuthUserFile, una direttiva a cui dovremo far passare come parametro il percorso in cui si trova
il file che contiene i dati necessari per l'autenticazione.
Abbiamo poi AuthGroupFile, una direttiva che può essere inserita a discrezione dell'amministratore del Web Server
nel caso in cui egli desideri fornire ad Apache una lista di utenti appartenenti ad uno stesso gruppo per i quali valgono
le medesime regole di autenticazione. Se intendiamo impostare AuthGroupFile, sarà sufficiente passare come
parametro a questa direttiva il percorso completo che porta al file contenente l'elenco degli appartenenti al gruppo.
Possiamo poi specificare tre ulteriori direttive: require user, require group e require valid-user. Nel caso di require
user è necessario indicare quali utenti sono autorizzati all'accesso; nel caso di require group è necessario indicare quali
gruppi di utenti sono autorizzati all'accesso; infine, nel caso di require valid-user tutti vengono autorizzati all'accesso.
Alla luce di ciò che abbiamo appena detto, possiamo fare un esempio completo di container per le direttive di
autorizzazione:
<Directory /PATH/area_riservata>
AllowOverride None
Options Indexes
AuthName Area Riservata
AuthType Basic
AuthUserFile /PATH/httpd/conf/.htpasswd
AuthGroupFile /PATH/httpd/conf/.htgroup
require user Amministratore
</Directory>
I filtri di Apache
Apache ha la possibilità di filtrare le richieste provenienti dai client e di soddisfare soltanto quelle trasmesse da utenti
eventualmente autorizzati alla fruizione delle risorse contenute nel server Web.
L'opera di filtraggio viene eseguita attraverso differenti procedure basate su particolari fasi di controllo; in generale vi
sono due modi attraverso i quali il Web server autorizza o meno la soddisfazione delle richieste: nel primo caso,
tramite il modulo "mod_access", confronta l'indirizzo IP del client in attesa di risposta con l'elenco di quelli che hanno
l'autorizzazione all'accesso; nel secondo caso, Apache non permetterà la soddisfazione della richiesta fino a quando il
client non sarà in grado di autenticarsi tramite la comunicazione di un nome_utente e di una parola_chiave validi per il
dominio di riferimento.
I comportamenti di "mod_access" possono essere configurati sulla base delle intenzioni dell'amministratore indicando i
dati necessari all'autenticazione come l'indirizzo IP e il nome di Host; si hanno poi tre direttive dal significato
abbastanza intuitivo che regolano le impostazioni di questo modulo:
1.
2.
Allow: autorizza la soddisfazione delle richieste se il client rispetta i criteri prestabiliti per l'accesso alle
risorse.
Deny: ha funzione contraria rispetto ad allow
e
3.
Order: rappresenta una direttiva complementare rispetto ad allow e deny, la sua funzione è quella di stabilire
in che ordine queste due istruzioni dovranno essere osservate.
A queste tre direttive basterà passare come parametro l'Host da abilitare o disabilitare; nel seguente esempio:
allow from lukeonweb.net
viene autorizzato l'accesso all'Host indicato.
L'uso di Order risulta abbastanza semplice è và scelto di volta in volta a seconda delle esigenze; in questo esempio:
order deny,allow
deny from all
allow from chasky.com
la direttiva dany ha precedenza su allow ("order deny,allow") e nessun Host ha la possibilità di accedere ("deny from
all") tranne quello autorizzato ("allow from chasky.com") .
Il filtraggio degli accessi può essere operato anche specificando l'indirizzo o gli indirizzi IP che si desidera siano
autorizzati ad accedere alle risorse:
<Directory />
order deny,allow
deny from all
allow from 127.0.0.1
</Directory>
Nell'esempio appena proposto, abbiamo autorizzato unicamente l'IP corrispondente al "localhost", tutti gli altri IP non
avranno la possibilità di veder soddisfatte le loro richieste.
Creazione dell'Index e gestione delle directory di Apache
Vi siete mai chiesti da cosa deriva il fatto che le HomePages della maggior parte dei siti internet siano rappresentate da
file chiamati "index.html", "index.php", ecc.?
Dietro a questa convenzione non ci sono motivazioni particolari se non la comodità dell'utente di non dover digitare per
intero una URL completa del filename ma di ricorrere ad una scorciatoia.
Dovendo accedere alla pagina:
http://www.dominio.it/index.php
non sarà quindi necessario scrivere l'intera URL ma basterà digitare:
http://www.dominio.it
del resto l'utente non è tenuto a sapere in che modo abbiamo chiamato la nostra Home e che estensione le abbiamo dato.
Così, per consuetudine si è deciso di chiamare "index" le pagine d'ingresso dei siti internet e di notificare questo dato
come predefinito al Web server in modo che la conversione dell'URL (da abbreviata ad estesa) fosse automatica ed
invisibile per l'utente.
Gli "index", vengono impostati tramite la direttiva DirectoryIndex nel file httpd.conf seguendo una sintassi molto
semplice che prevede la chiamata della direttiva seguita dal nome del file che dovrà svolgere le funzioni di "pagina di
default" della DocumentRoot.
Visualizzando il file di configurazione di Apache, troveremo sicuramente già impostate una lunga serie di possibili
pagine "index" complete di estensioni:
DirectoryIndex index.html index.shtml index.php
Naturalmente, nulla ci vieta di impostare a piacere il nome della nostra Home intervenendo sull'apposita voce.
Ad esempio potremmo decidere che la nostra pagina di default sia rappresentata dal file "pippo.html". In tal caso
dovremo impostare come segue:
DirectoryIndex pippo.html
Quando nella DocumentRoot non è presente una pagina "index", può verificarsi il fenomeno del Directory listings, in
questo caso infatti il Web server non trovando una pagina d'ingresso restituisce una lista delle risorse contenute
all'interno della directory.
Il Directory listings può essere voluto, come in quei siti che vengono messi in piedi semplicemente per consentire il
download di determinati file tramite link; diversamente il Directory listings può essere involontario perchè il
Webmaster non crea una pagina Home con uno dei nomi inseriti in httpd.conf, oppure, dimentica di passare il nome
della propria pagina home come parametro a DirectoryIndex. Naturalmente non verrà prodotto alcun elenco se la
necessaria direttiva non verrà abilitata.
In caso di Directory listings involontario, il problema sarà facilmente risolvibile inserendo nella DocumentRoot un
file (anche vuoto) recante un nome indicato in httpd.conf o aggiungendo un nome seguito da una estensione valida in
corrispondenza di DirectoryIndex.
Il Directory listings, produce quindi in all'alternativa all'HomePage un semplice documento Html recante una lista dei
file presenti nella DocumentRoot che saranno a cui si potrà accedere tramite link.
Questo fenomeno è reso possibile da un modulo chiamato "mod_autoindex".
La visualizzazione del "listing" è configurabile tramite alcune voci:
•
•
•
•
•
•
•
•
•
•
•
HeaderName: consente di indicare il nome di un file da visualizzare automaticamente come "header"
precedentemente alla lista delle risorse.
IndexOptions: permette di impostare la visualizzazione dei contenuti, compresa la possibilità di nascondere
particolari che non si vogliono rendere visibili.
IndexIgnore: consente di non mostrare certi tipi di file interni alla directory.
AddDescription: consente di descrivere determinati file.
Addalt: associa il tag "alt" a determinati file.
AddIcon: associa un'icona a determinati file.
AddAltByType: consente di associare il tag "alt" a determinati file sulla base della loro tipologia.
AddIconByType: consente di associare un'icona a determinati file sulla base della loro tipologia.
AddAltByEncoding: consente di associare il tag "alt" a determinati file sulla base del "MIME Encoding".
AddIconByEncoding: consente di associare un'icona a determinati file sulla base del "MIME Encoding".
DefaultIcon: indica un'icona predefinita da mostrare quando non è stata associata alcuna icona ad un tipo di
file.
Domini virtuali di Apache
Con il nome "domini virtuali", o Virtual Hosts, si identificano tutti gli Hosts che vengono configurati in un server
Web in aggiunta all'Host originario. In pratica, con i "domini virtuali" avremo la possibilità di far operare
separatamente più server in una stessa macchina, ognuno con un proprio dominio ("www.primo_server.ext",
"www.secondo_server.ext"..).
Esistono due tipologie di Virtual Hosts: quelli che fanno capo a differenti indirizzi IP (IP Based Virtual hosts) e,
quelli che vengono distinti sulla base del nome (host-based o non IP virtual hosts). In entrambi i casi, abbiamo la
possibilità di far convivere più siti internet, ognuno con il proprio "www.dominio.ext", su una stessa macchina. Per chi
fa "Hosting", cioè coloro che per mestiere vendono porzioni di spazio Web destinate ad ospitare siti internet, la
possibilità di creare Virtual Hosts rappresenta un indubbio vantaggio sia a livello operativo che economico.
Se disponiamo di più indirizzi IP possiamo configurare dei "domini virtuali" IP Based. Dal punto di vista di Apache,
questo tipo di configurazione può essere operata in due modi: utilizzare un unico processo http che faccia capo a tutti i
domini, oppure, dedicarne uno per ognuno di essi; se disponiamo di una macchina abbastanza potente in termini di
risorse, la seconda opzione è certamente preferibile, tutto dipende dal numero di domini che desideriamo siano presenti
nel nostro computer Server.
Se scegliamo di concedere ad ogni dominio un proprio httpd, dovremo modificare il file http.conf intervenendo
sull'istruzione Listen ("ascolta"); ad essa vanno passati come parametri un indirizzo IP (o un nome di dominio) e il
numero della porta che ogni httpd utilizzerà per mettersi in "ascolto" pronto a soddisfare le richieste provenienti dai
client. Un esempio potrebbe essere questo:
Listen 111.111.1.1:80
Listen 111.111.1.2:81
oppure
Listen www.nome_dominio.ext:80
Listen www.altro_nome_dominio.ext:81
Come avrete avuto modo di notare, ad ogni dominio viene dedicata una porta diversa.
Se invece vogliamo configurare un solo httpd per tutti i "domini virtuali", dovremo indicare in httpd.conf per ogni
dominio un container simile a questo:
<VirtualHost www.nome_dominio.ext>
ServerAdmin email@nome_dominio.ext
DocumentRoot /PATH/nome_cartella
ServerName www.nome_dominio.ext
ErrorLog /PATH/error.log
CustomLog /PATH/nome_access_log
</VirtualHost>
Niente di particolarmente complesso, dall'esempio si comprende facilmente che per costruire il container sono
necessari:
1.
2.
3.
4.
5.
6.
La direttiva VirtualHost seguita dal nome del "dominio virtuale" che intendiamo porre in essere.
L'indirizzo e-mail dell'Admin.
Il percorso completo verso la DocumentRoot del nuovo dominio.
Il nome del server (ServerName).
Il percorso in cui si trovano i file di "log" di Error
Il percorso in cui si trovano i "log" sul traffico delle risorse.
Nel caso dei domini host-based, basati sul nome, il discorso è altrettanto semplice. Nel file httpd.conf dovremo
indicare innanzitutto l'indirizzo IP come parametro all'istruzione NameVirtualHost, dopo di che costruiremo un
container in cui dovremo indicare l'IP e il nome del ServerName:
NameVirtualHost 111.111.1.1
<VirtualHost 111.111.1.1>
ServerName www.nome_server.ext
DocumentRoot /PATH/nome_cartella
</VirtualHost>
<VirtualHost 111.111.1.1>
ServerName www.nome_server.ext
DocumentRoot /PATH/nome_cartella
</VirtualHost>
Errori su Apache e la loro gestione
L'errore più noto che può essere notificato da Apache è il 404, di cui abbiamo parlato in precedenza, il famoso "File not
found". Alla base di questa notifica vi è una dinamica abbastanza semplice e conosciuta:
1.
2.
3.
Il client vorrebbe accedere ad una risorsa è digita un'URL o clicca su un link per comunicare la richiesta.
Il Web server non trova la risorsa desiderata nel percorso indicato, registra l'errore nei "log" e invia una
notifica.
Il browser del client visualizza una pagina Html contenente la notifica dell'errore riscontrato.
La maggior parte delle risposte di Apache a richieste che non possono essere soddisfatte sono configurabili, è
sufficiente agire sulla direttiva ErrorDocument indicando la tipologia di errore ("numero", o "codice" di erore) e il
messaggio che si desidera venga visualizzato dall'utente. In alternativa è possibile redirigere il browser del client su una
pagina di notifica (tipo "error.html") in cui dare al navigatore maggiori informazioni, scusarsi del disagio arrecato o
fornire consigli su come reperire ugualmente la risorsa cercata.
Apache notifica principalmente due tipologie di errore: i 4XX, derivanti dalle richieste dei client e i 5XX dovuti alle
risposte dei Web server.
Tra i 4XX abbiamo:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
400: la richiesta non viene recepita da Apache in quanto incomprensibile (ad es: un errore sintattico nella
digitazione dell'URL).
401: essendo necessaria un'autorizzazione per accedere alla risorsa richiesta, coloro che non la possiedono non
potranno accedere ad essa.
402: la risorsa richiede un qualche forma di pagamento per poter essere accessibile.
403: Apache rifiuta di permettere l'accesso all'utente.
404: File Not Found
405: viene notificato un errore nel metodo con il quale viene effettuata la richiesta.
406: la risposta del server non è compatibile con la tipologia di richiesta.
407: la richiesta non può essere soddisfatta senza una previa autenticazione col proxy.
408: la richiesta del client si è fatta attendere oltre i tempi consentiti dalla Web Server ("Time Out").
409: notifica dei conflitti tra richiesta e risposta desiderata.
410: risposta non disponibile, neanche tramite un redirect.
411: non sarà possibile una risposta fino alla definizione del "Content-Length" (lunghezza richiesta).
412: prerequisito necessario alla soddisfazione della richiesta fallito.
413: la richiesta richiede una risorsa più grande di quella che Apache è in grado di processare.
414: URL troppo lunga proveniente dalla richiesta.
415: il formato della richiesta non è supportato.
Per quanto riguarda le notifiche 5XX, abbiamo invece appena sei voci:
•
•
•
•
•
•
500: errore interno al server, generalmente causato da un malfunzionamento del programma che mette a
disposizione il servizio.
501: server non implementato per poter soddisfare la tipologia di richiesta.
502: il gatway o il proxy collegati al server inviano una risposta errata.
503: la richiesta inviata è temporaneamente inesaudibile.
504: il gatway o il proxy collegati al server inviano una risposta andando oltre il tempo concesso prima della
notifica del "Time Out".
505: la versione del protocollo HTTP attraverso cui il client ha effettuato la richiesta non è supportata.
Opzioni avanzate di Apache: alias e redirect
Riassumendo e semplificando al massimo ciò di cui abbiamo parlato nel capitolo iniziale di questa guida, possiamo dire
che lo schema client >> server su cui si basa la Rete si configura come un continuo avvicendarsi di richieste e di
risposte gestite dai Web server come Apache. Il client richiede un'informazione e il Web server, continuamente in
"ascolto", si occupa di reperirla all'interno del computer server per poi inviarla al client.
Abbiamo così descritto uno schema "ideale" basato sulla dinamica domanda/risposta.
Questo schema, per essere sempre efficiente, deve poter prevedere e gestire le possibili eccezioni.
Sempre all'inizio di questa guida, abbiamo detto che seguendo il protocollo HTTP le richieste vengono inviate al
server tramite la digitazione di URL indicanti i percorsi che è necessario percorrere per accedere alle risorse richieste.
Ma cosa accade quando non vi è completa corrispondenza tra posizione delle informazioni ospitate nel server e URL?
Quali metodi vengono utilizzati per soddisfare comunque le richieste dei client?
Se noi digitiamo l'URL "http://www.dominio.ext/informazione.php" o clicchiamo sul link corrispondente, potrebbe
accadere che la risorsa che cerchiamo non si trovi più o non sia più interamente contenuta nel percorso indicato. Grazie
ad alcune funzionalità (le ormai note direttive) di Apache sarà comunque possibile soddisfare la richiesta. Stiamo
parlando dell'aliasing e del redirecting.
L'aliasing, basato sulla direttiva alias, non è altro che un processo di translazione delle URL. Il percorso indicato dal
client sarà valido anche per l'accesso ad informazioni allocate esternamente rispetto alla DocumentRoot.
L'aliasing è un sistema vantaggioso sia per il client che vede la sua richiesta soddisfatta in modo trasparente, sia per la
sicurezza del Web server che può gestire risorse al di fuori dello spazio accessibile dal Web rendendole quindi meno
esposte ad intenzioni malevole.
L'aliasing si ottiene passando alla direttiva alias sia l'URL che verrà digitata dal client per la richiesta, sia il percorso
reale che indica l'effettiva posizione delle risorse.
Quindi se una determinata risorsa, ad esempio un'immagine, verrà richiesta tramite l'URL http://www.sito.ext/img.gif e
quest'ultima si trova invece in una posizione esterna alla DocumentRoot "PATH/img.gif", basterà passare entrambe le
informazioni come parametri ad alias per ottenere il risultato desiderato.
La direttiva redirect è gestita dallo stesso "modulo" di alias, "mod_alias", ma si comporta in modo differente. Con
redirect, infatti, l'URL digitato tramite il client non verrà traslato ma sostituito da uno nuovo. Questo fenomeno è
molto noto presso i navigatori di Internet, spesso infatti capita di dirigerci verso una determinata pagina ed essere
rediretti verso altri documenti.
Per permettere il redirect, possiamo passare all'omonima direttiva tre parametri:
1.
2.
3.
status: indica il messaggio inviato al client all'atto del redirect; può essere "temp", quindi
temporaneo,"permanent", se definitivo o "gone" quando invece di un redirect si ha una situazione di
irreperibilità della risorsa.
prefisso (prefix URL): punto di partenza necessario per dar vita al redirect.
URL di destinazione.
Un esempio di redirect potrebbe essere questo:
Redirect temp
/nome_cartella
http://www.sito.ext/cartella_di_destinazione/