No more maintained.
Now just a test in a lab.
Error handling e response header
Gli header HTTP e la loro customizzazione. Gestione degli errori.
Gestione degli errori su Apache
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Se Apache verifica che la richiesta effettuata da un client non può essere soddisfatta per un qualsiasi motivo, ne tiene traccia sull'error log ed invia un messaggio di errore al client.
La configurazione standard di Apache, fa si che ad ogni errore venga generata una pagina HTML che contiene l'error code indicativo delle ragioni che hanno generato l'errore.
Tramite la direttiva ErrorDocument si ha la possibilità di customizzare la risposta del server per ogni errore. Richiede due parametri: l'error code a cui riferirsi e l'azione da eseguire (di solito la pagina da visualizzare).
Si ha la possibilità di utilizzare il template di default generato on-the-fly dal server e customizzare semplicemente il messaggio che viene visualizzato.
ErrorDocument 404 "Risorsa non disponibile"
Altrimenti si ha la possibilità di redirezionare ad una pagina html del tutto customizzata.
ErrorDocument 404 /errors/404.html
Si può anche decidere di far visualizzare l'home page di un sito ogni volta che si cerca di accedere ad una pagina non trovata:
ErrorDocument 404 /
La soluzione di customizzazione dei messaggi di errore risulta una pratica comune ed elegante per l'erogazione del servizio (talvolta vengono utilizzati anche, piccoli script cgi per generare in modo del tutto dinamico le pagine customizzate).
La direttiva ErrorDocument presenta delle piccole limitazioni:
- Se la direttiva viene utilizzata per puntare ad uno script esterno al server non si possono definire nessun tipo di variabile.
- Non è possibile utilizzare la direttiva ErrorDocument per eseguire un redirect per l'errore 401 Authentification Error, ad una risorsa esterna.
Controllare i Response-header
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Apache, come ogni web server, quando esaudisce una richiesta invia delle informazioni aggiuntive al client, le quali consitono in:
- HTTP status line che contiene il response code
- Content-Type Header
- Uno o più HTTP Response Header [Opzionale]
- Uno o più HTTP Entity Header [Opzionale]
- Body (il file, pagina html, immagine o altro, richiesto dal client)
Il Content-Type è obbligatorio, mentre gli altri header sono opzionali.
Anche se un header può avere qualsiasi nome, il protocollo HTTP definisce specifici headers con uno specifico significato. Gli header che possono essere presenti nelle risposte di un web server possono essere di due tipi: response header ed entity header.
Response Headers
Aggiungono ulteriori informazioni circa il messaggio come dettagli per il caching ed eventuali warning.
Header che aggiunge informazioni per il caching per un proxy server e del proprio browser:
Cache-Control
Connection
Date
Direttiva generica che viene utilizzata il cache control con i client che utilizzano il protocollo HTTP/1.0
Pragma
Trailer
Transfer-Encoding
Upgrade
Via
Warning
Entity Headers
Allow
Content-Encoding
Content-Language
Content-Lenght
Content-Location
Content-MD5
Content-Range
Content-Type
Expires
Last-Modified
Apache stesso o alcuni moduli, come mod_expires, settano i valori di questi headers, ma a livello di configurazione si ha la possibilità di settare degli header custom tramite la direttiva Headers (valida in ogni contesto) gestita dal modulo mod_headers, il quale non fa parte della configurazione standard di Apache.
Non tutti i vari header sono modificabili tramite questa direttiva poiché vengono inzializzati poco prima dell'inizio della risposta del client, come Servers e Date Headers.
La direttiva Headers ha 4 modalità di impiego:
set Opzione che permette di inizializzare l'Header. Il nome dell'Header non è case sensitive
Headers set Pippo Pluto
L'header Pippo è settato con valore Pluto
append Esegue l'append di un valore ad un header già esistente
Inizializzazione dell'header Pippo e successiva aggiunta del valore Bruno
Headers set Pippo Pluto
Headers append Pippo Bruno
add Alternativa all'opzione di append con la differrenza che la seguente opzione esegue un replace del valore dell'Header.
unset Per eseguire l'unset dei vari headers, compresi quelli settati da altri moduli di Apache.
Headers unset Receipe
Settaggio dell'expiry time
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Il protocollo HTTP definisce l'header Expire per dare un'indicazione al proxy server o a direttamente al browser su come gestire il caching della risorsa richiesta.
La direttiva che permette il settaggio dell'Expires Header è ExpiresActive la quale è gestita dal modulo mod_expire (non è incluso nella configurazione standard di Apache):
ExpiresActive on
La direttiva può essere specificata sia per i singoli VirtualHost, che per directory o semplicemente per un file ma per far si che venga settato l'expires Header occorre definire anche le seguenti direttive:
ExpiresDefault Direttiva che setta l'expiry time di default per tutti i file:
ExpiresDefault A86400
oppure
ExpiresDefault M86400
La differenza sta nel prefisso A e M, il primo fa si che il tempo venga calcolato da quando il client ha ricevuto la risorsa, il secondo invece fa si che il calcolo dell'expiry time dipenda dalla data di creazione della risorsa. In entrambi i casi i valori numerici sono espressi in secondi.
Occorre sottolineare che l'uso del prefix M non è funzionale in due casi:
- La risorsa richiesta non è un file fisicamente che risiede su un disco, per cui è impossibile dedurre la sua data di crezione.
- Ammettiamo che si abbia configurato expiry time di un giorno (86400 secondi), allo scadere di questo giorno la risorsa in questione non verrà cacheata finchè non si modificherà il suo modification time.
ExpiresByType Direttiva che permette di settare l'expiry time di una risorsa a seconda del MIME type.
ExpiresByType image/gif A2419200
In entrambe le direttive è possibile sostituire i numeri in un formato più verboso, tramite i prefissi access o modification seguiti da plus e dal periodo:
Settaggio dell'expiry time a seconda del MIME type in entrambi i modi
ExpiresByType image/gif A2419200
ExpiresByType image/gif "access plus 1 month"
Settaggio dell'expiry time di default in entrambi i modi
ExpiresDefault M86400
ExpiresDefault "modification plus 1 day"
Controllo dei robots
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Per far si che gli utenti di Internet vengano a visitare il proprio sito web occorre pubblicizzarlo.
Un metodo efficente è quello di affidarsi ai vari motori di ricerca i quali utilizzano dei "robot" ovvero degli agent automatici che effettuano un vero e proprio scanning di un sito web, prelevando e indicizzandone le pagine, per essere inserite nei database usati per le richieste sui motori.
Per avere un minimo di controllo di ciò che i vari robot possono o non possono indicizzare ci si può appoggiare a tre opzioni:
robots.txt file
Deve risiedere nella DocumentRoot del sito ed il nome deve essere robots.txt scritto in minuscolo.
Deve contenere la lista dei vari user-agent o i prefissi dei vari user-agent seguiti da una serie di path di risorse che non dovrebbero essere indicizzate. Un esempio di robots.txt (che impedisce l'accesso a due directory) è:
User-Agent: *
Disallow: /cgi-bin/
Disallow: /scripts/
Con questo esempio, invece, si dice ad ogni robot di non indicizzare alcuna parte del sito:
User-Agent: *
Disallow: /
Da ricordarsi che anche robots.txt viene cacheato dai vari spider e che è possibile avere un minimo di controllo tramite la direttiva ExpiresDefault:
<Location /robots.txt>
ExpireDefault "access 1 days"
</Location >
HTML ROBOTS meta tags
Molti robots oltre che a controllare il file robots.txt verificano anche i meta tag all'interno dei documenti HTML, che possono essere customizzate secondo le proprie esigenze. Per esempio:
<META NAME="ROBOTS" CONTENT="INCLUDE, FOLLOW">
Direttive allow e deny
Tramite la direttiva BrowserMatch e SetEnvIf è possibile avere un maggior controllo su cosa indicizza il robots, rispetto all'uso dei META tag e del file robots.txt. Per esempio:
BrowserMatchNoase .*googlebot.* robot
BrowserMatchNoase .*yahoobot.* robot
SetEnvIf Remote_Host .*norobot\.com robot
<Location /not-indexable/>
order allow,deny
allow from all
deny from env=robot
</Location>
Bisogna sempre sottolineare che i metodi indicati per il controllo dei robots funzionano solo se i robot si attengono alle specifiche standard. Se hanno finalità maligne, possono ignorare i contenuti dei file robots.txt o dei META TAG e presentarsi come USER-AGENT normali, bypassando le limitazioni indicate.
Sotto certi aspetti, inoltre, quanto definito in robots.txt può dare ad un cracker informazioni utili su path che si intendono nascondere per cui è opportuno considerare se le informazioni scritte nel file robots.txt possono comportare rischi in termini di sicurezza.
Robots entry nell'access log di apache
Tipo Infobox: STDOUT - Skill: 2- JUNIOR
E' normale trovare traccia delle visite di robot vari negli access log di un server web. Segue un esempio delle GET effettuate da vari robots per il file robots.txt
65.116.145.15 - - [29/Jan/2002:13:25:24 +0100] "GET /robots.txt HTTP/1.1" 404 - "-" "Mozilla/4.0 compatible ZyBorg/1.0 ([email protected]; http://www.WISEnutbot.com)"
195.130.233.24 - - [04/Mar/2002:06:42:30 +0100] "GET /robots.txt HTTP/1.0" 404 - "-" "SearchTone2.0 - IDEARE"
216.239.46.98 - - [13/Nov/2002:04:07:19 +0100] "GET /robots.txt HTTP/1.0" 200 4026 "-" "Googlebot/2.1 (+http://www.googlebot.com/bot.html)"
Content Digest dei documenti serviti via HTTP
Tipo Infobox: DESCRIPTION - Skill: 3- INTERMEDIATE
Apache tramite una direttiva sperimentale, può calcolare il checksum del body di un una risorsa inviata tramite il protocollo HTTP.
Il checksum o message-digest è inviato tramite l'header Content-MD5 e tramite una striga (MD5 encoded) di comparazione si può verificare se il body abbia subito qualche alterazione, in caso di riscontro di alterazione del body viene generato un messaggio di avviso.
Per abilitare questa funzione occorre abilitare la direttiva ContentDigest, la quale non richiede nessun tipo di modulo aggiuntivo poichè è inclusa nel core di apache. Gli unici parametri che accetta come argomenti sono on ed off:
ContentDigest on
ContentDigest off
E' una direttiva che si preferisce tenere disabilitata sia perchè pochi browser supportano questa feature di check del body tramite checksum sia perchè il checksum deve essere calcolato ogni volta che viene richiesta una risorsa senza avere nessuna possibilità di caching riducendo così le performance del webserver.
Send-as-is: Invio dei contenuti senza aggiunta di header
Tipo Infobox: TIPS - Skill: 4- ADVANCED
Apache normalmente aggiunge headers alla risposta delle singole richieste, settati tramite i moduli mod_mime e mod_expire.
E' possibile però impedire l'invio di header tramite il modulo mod_asis che non ha nessun tipo di direttiva per essere abilitato, in quanto basta associare le parole send-as-is al MIME type:
httpd /send-as-is.
Alternativamente si può definire una directory dove risiedono tutte le risorse che dovranno essere inviate senza header aggiuntivi:
<Directory /home/www/no-headers/>
SetHandler send-as-is
</Directory>