Messages d'erreur personnalisés

Une fonctionnalité additionnelle permet aux webmasters de configurer la réponse d'Apache à certaines erreurs ou problèmes.

Il est possible de définir des réponses personnalisables comme devant être activées lorsque le serveur détecte une erreur ou un problème.

Si un script se crashe et provoque l'envoi d'une réponse "500 Server Error", cette dernière peut être remplacée soit par un texte plus convivial, soit par une redirection vers une autre URL (locale ou externe).
Comportement
Ancien comportement

httpd 1.3 de NCSA renvoyait d'antiques et obscurs messages d'erreur ou de problème qui la plupart du temps n'avaient aucune signification pour l'utilisateur, et ne permettaient pas de journaliser les symptomes qui les avaient causés.

Nouveau comportement

Il est possible de demander au serveur :

  1. d'afficher un autre texte à la place du message NCSA codé en dur, ou
  2. rediriger vers une URL locale, ou
  3. rediriger vers une URL externe.

La redirection vers une autre URL peut être utile, mais seulement s'il est possible de transmettre certaines informations qui pourront être utilisées pour expliquer et/ou journaliser l'erreur ou le problème plus clairement.

Pour y parvenir, Apache va définir de nouvelles variables d'environnement de style CGI :

REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05 9000/712)
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc
REDIRECT_QUERY_STRING=
REDIRECT_REMOTE_ADDR=121.345.78.123
REDIRECT_REMOTE_HOST=ooh.ahhh.com
REDIRECT_SERVER_NAME=crash.bang.edu
REDIRECT_SERVER_PORT=80
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15
REDIRECT_URL=/cgi-bin/buggy.pl

Notez le préfixe REDIRECT_.

Au minimum REDIRECT_URL et REDIRECT_QUERY_STRING seront transmises à la nouvelle URL (en supposant qu'il s'agit d'une inclusion ou d'un script cgi). Les autres variables ne seront présentes que si elles existaient avant que l'erreur ou le problème ne survienne. Aucune d'entre elles ne sera définie si votre directive ErrorDocument spécifie une redirection externe (toute URL commençant par un protocole du style http:, même si elle fait référence au même hôte que le serveur).

Configuration

L'utilisation de la directive ErrorDocument est activée pour les fichiers .htaccess si la directive AllowOverride est positionnée dans cette optique.

Voici quelques exemples...

ErrorDocument 500 /cgi-bin/crash-recover
ErrorDocument 500 "Toutes nos excuses, notre script s'est crashé."
ErrorDocument 500 http://xxx/
ErrorDocument 404 /Lame_excuses/not_found.html
ErrorDocument 401 /Subscription/how_to_subscribe.html

La syntaxe est la suivante :

ErrorDocument <code à 3 chiffres> <action>

où action peut être :

  1. Un texte à afficher. Entourez-le de guillemets (").
  2. Une URL externe vers laquelle on sera redirigé.
  3. Une URL locale vers laquelle on sera redirigé.
Messages d'erreur et de redirection personnalisés

Lors d'une redirection d'URL, Apache a modifié son comportement et les scripts ou inclusions côté serveur disposent maintenant de variables d'environnement supplémentaires.

Ancien comportement

Un script vers lequel une requête avait été redirigée avait accès aux variables CGI standards, sans indication sur l'origine de la redirection.

Nouveau comportement

Un nouveau jeu de variables d'environnement va être initialisé à des fins d'utilisation par un script vers lequel une requête aura été redirigée. Chaque nouvelle variable sera préfixée par REDIRECT_. Les variables d'environnement REDIRECT_ sont créées à partir des variables d'environnement CGI existant avant la redirection, et renommées en leur ajoutant le préfixe REDIRECT_ ; par exemple, HTTP_USER_AGENT devient REDIRECT_HTTP_USER_AGENT. En plus de ces nouvelles variables, Apache va définir REDIRECT_URL et REDIRECT_STATUS pour aider le script à remonter à l'origine de la redirection. L'URL originale et l'URL de redirection peuvent être enregistrées dans le journal des accès.

Si la directive ErrorDocument spécifie une redirection locale vers un script CGI, ce dernier doit ajouter un en-tête "Status:" dans sa sortie afin de s'assurer du bon acheminement jusqu'au client de la condition d'erreur qui a provoqué cette redirection. Par exemple, un script Perl spécifié par une directive ErrorDocument pourrait contenir ce qui suit :

...
print "Content-type: text/html\n";
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"};
...

Si un script est dédié à la gestion d'une condition d'erreur spécifique, telle que 404 Not Found, il peut utiliser le code et le texte de l'erreur spécifiques à la place.

Notez que si la réponse contient un en-tête Location:, le script doit émettre un en-tête Status: approprié (tel que 302 Found) afin de provoquer une redirection au niveau du client. Dans le cas contraire, l'en-tête Location: risque de n'avoir aucun effet.