Personalizzare ed analizzare i messaggi d’errore di Apache

Fra le diverse serie di codici di stato HTTP, inclusi nelle risposte del server, vi è la 4xx e 5xx che segnalano al client (browser) che è avvenuto un errore.

Un esempio tipico, è il codice 404 Not Found che viene visualizzato dal browser, quando digitiamo un indirizzo URL richiede una risorsa (pagina web) che non esiste.

Di seguito, riporto i possibili codici di errore, e la rispettiva spiegazione:

• 400 Bad Request, quando la richiesta inviata dal client non è formulata correttamente ed il server non può processarla;
• 401 Unauthorized, quando il contenuto è protetto da un processo di autenticazione dell’utente che però non ha dato riscontro;
• 402 Payment Required (codice proposto ma non ancora entrato in uso);
• 403 Forbidden, quando il client non ha i necessari permessi per accedere ad una certa risorsa via web (per esempio, quando i permessi di file o directory non sono impostati correttamente);
• 404 Not Found, quando il client richiede una risorsa (pagina web) che non esiste;
• 405 Method Not Allowed, quando il metodo di sottomissione della richiesta non è consentito (per esempio, il client ha inviato dati con GET invece di usare POST);
• 406 Not Acceptable, quando il server è in grado di generare una risposta in un formato non accettabile dal client;
• 407 Proxy Authentication Required, quando il client deve prima ottenere l’autenticazione sul server Proxy;
• 408 Request Timeout, quando il server attende per un tempo troppo lungo l’invio della richiesta dal client;
• 409 Conflict, quando la richiesta è in conflitto con un’altra (per esempio quando due client cercano di modificare contemporaneamente la stessa risorsa);
• 410 Gone, quando una risorsa non è disponibile e non lo sarà in futuro;
• 411 Length Required, quando la richiesta non specifica la lunghezza del suo contenuto;
• 412 Precondition Failed, quando il server non soddisfa i requisiti richiesti dal client;
• 413 Payload Too Large, quando la richiesta inviata dal client è troppo grande ed il server non è in grado di processarla;
• 414 URI Too Long, quando la richiesta è stata inviato con un URI troppo lungo;
• 415 Unsupported Media Type, quando la richiesta include un formato di file non supportato dal server;
• 416 Range Not Satisfiable, quando il client ha richiesto una porzione di file che non è disponibile o non delimitata correttamente;
• 417 Expectation Failed, quando il server non soddisfa i requisiti del campo Expect;
• 418 I’m a teapot, usato per visualizzare Easter egg (sorprese) in alcuni siti;
• 421 Misdirected Request, quando la richiesta era diretta ad un serve non in grado di rispondere;
• 422 Unprocessable Entity, quando la richiesta è corretta ma non può essere processata a causa di errori semantici;
• 423 Locked, quando la risorsa richiesta è bloccata;
• 424 Failed Dependency, quando la richiesta fallisce perché è fallita una richiesta precedente;
• 426 Upgrade Required, quando il client deve passare ad un protocollo diverso;
• 428 Precondition Required, quando il server richiede una richiesta condizionale;
• 429 Too Many Requests, quando il cliente ha sottomesso troppe richieste in un certo tempo;
• 431 Request Header Fields Too Large, quando l’intestazione della richiesta inviata dal client è troppo grande;
• 451 Unavailable For Legal Reasons, quando il client richiesta una risorsa non disponibile per motivi legali. Il codice è un riferimento al libro Fahrenheit 451.
• 500 Internal Server Error, quando si verifica un errore generico e la richiesta del client non può essere soddisfatta;
• 501 Not Implemented, quando il server non riconosce il metodo della richiesta o non è in grado di processarla correttamente;
• 502 Bad Gateway, quando il server agisce come portale di indirizzamento delle richieste verso un altro server che non risponde correttamente;
• 503 Service Unavailable, quando il server non è disponibile (perché riceve troppe richieste o è spento per manutenzione)
• 504 Gateway Timeout, quando il server agisce come portale di indirizzamento delle richieste verso un altro server che non risponde in tempo utile;
• 505 HTTP Version Not Supported, quando il server non supporta il protocollo HTTP usato dal client;
• 506 Variant Also Negotiates, quando la negoziazione del contenuto finisce in un riferimento circolare;
• 507 Insufficient Storage, quando il server non è in grado di memorizzare i file necessari a processare la richiesta;
• 508 Loop Detected, quando il server ha rilevato una iterazione infinita nel processare la richiesta;
• 510 Not Extended, quando sono richieste estensioni delle richieste per poterle soddisfare;
• 511 Network Authentication Required, quando il client deve autenticarsi per poter accedere alla rete.

Pagine d’errore personalizzate

Il server web, predispone pagine d’errore generiche da visualizzare quando è necessario; tuttavia, queste pagine sono essenziali, non offrono molti dettagli e potrebbero intimidire gli utenti del sito.

E’ buona norma rimpiazzare queste pagine predefinite del server, con versioni personalizzate che mostrino messaggi:

1. più amichevoli ed informativi,
2. tradotti in più lingue,
3. con una formattazione grafica più congrua al design del sito.

Per configurare le pagine d’errore personalizzate di Apache, per i codici d’errore più comuni, ho incluso nel file .htaccess del sito, le seguenti direttive:

ErrorDocument 403 /pages/403.html
ErrorDocument 404 /pages/404.html
ErrorDocument 429 /pages/429.html
ErrorDocument 500 /pages/500.html
ErrorDocument 503 /pages/503.html
ErrorDocument 504 /pages/504.html

Per creare le pagine, è stato sufficiente processarle con Pelican nel modo usuale.

Analisi del registro di Apache

Tutte le richieste e risposte processate dal server Apache vengono registrate in un apposito file dei Logs. Con WebFaction, i Logs di ogni sito ed applicazione sono disponibili nella directory $HOME/logs; vi sono diversi file di log:

1. frontend/access_[nome sito].log, registra gli accessi al sito;
2. frontend/access_[nome sito]_php.log, registra gli accessi alle applicazioni condivise del server Apache, richieste tramite il sito (per esempio le applicazioni CGI/PHP);
3. frontend/error_[nome sito].log, registra gli errori del sito;
4. frontend/error_[nome sito]_php.log, registra gli errori del sito;
5. user/access_[nome applicazione]].log, registra gli accessi ad una particolare applicazione registrata nel pannello di controllo di WebFaction;
6. user/error_[nome applicazione]].log, registra gli accessi ad una particolare applicazione registrata nel pannello di controllo di WebFaction;

Nel log degli accessi vengono registrate queste informazioni:

• l’indirizzo IP del client
• la data e l’ora di accesso
• il metodo HTTP usato
• l’URL richiesto
• la descrizione del client che ha inviato la richiesta

Per esempio, un record di accesso nel file di log, appare come di seguito:

216.244.66.200 - - [05/Jun/2017:04:39:12 +0000] "GET /robots.txt HTTP/1.1" 200 176 "-" "Mozilla/5.0 (compatible; DotBot/1.1; http://www.opensiteexplorer.org/dotbot, help@moz.com)"

Invece, un record di errore nel file di log, appare come di seguito:

2017/05/29 03:46:33 [error] 40832#0: *45384374 open() "/home/robertof/webapps/static_ipertesti_com/tag_inkscape.html" failed (2: No such file or directory), client: 66.249.64.65, server: www.ipertesti.com, request: "GET /tag_inkscape.html HTTP/1.1", host: "www.ipertesti.com"

Per analizzare i file di log, esistono molti programmi in grado di leggere e interpretare i file di log, e generare rapporti statistici. In WebFaction, sono disponibili AWStats e Webalizer.

Ho scelto di usare AWStats perché è più aggiornato; per installarlo, creo una nuova applicazione tramite il Pannello di Controllo; nel campo “Extra info” specifico il nome del sito di cui voglio analizzare i file di Log.

Dopo aver creato l’applicazione di AWStats, tramite il Pannello di Controllo l’ho registrata nel sito web, e gli ho assegnato un percorso URL di accesso.

A questo punto, l’applicazione AWStats è attiva ed accessibile online; tuttavia, occorre impostare l’autenticazione HTTP per prevenirne l’accesso da parte di tutti gli utenti del web.

Perciò edito il file .htaccess nella cartella $HOME/webapps/[nome directory di AWStats] ed imposto le seguenti istruzioni:

AuthUserFile /home/[nome account WebFaction]/webapps/[nome directory di AWStats]/.htpasswd
AuthName EnterPassword
AuthType Basic
require valid-user

# Hide files starting with a dot (.htaccess and .htpasswd in particular)
<Files .*>
order allow,deny
deny from all
</Files>

Infine, creo il file criptato .htpasswd che contiene la password per accedere ad AWStats, con il seguente comando:

htpasswd -c .htpasswd [nome account WebFaction]

A questo punto, non resta che digitare 2 volte la password ed il gioco è fatto! Non resta che esaminare i report di AWStats ed in particolare la sezione dedicata ai codici di stato HTTP.

Riferimenti

1. List of HTTP status codes
2. Custom Error Responses
3. WebFaction Reviewing Logs
4. WebFaction Accessing Logs
5. Webfaction Webstats
6. Password Protecting a Directory with a Static/CGI/PHP App

Libri suggeriti