blob: 0fd63439c547212bbff15fc710cff15283364ce8 [file] [log] [blame]
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
<!-- English Revision: 151405 -->
<!-- French Translation by Vincent Deffontaines, review by alain B -->
<!--
Copyright 2005 The Apache Software Foundation or its licensors, as
applicable.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<manualpage metafile="custom-error.xml.meta">
<title>Personnalisation des Messages d'Erreurs</title>
<summary>
<p>Il est possible à un administrateur Apache de configurer les réponses
d'Apache dans les cas où des erreurs ou problèmes se présentent.</p>
<p>Des réponses paramétrables peuvent être définies pour être activées au
cas où le serveur détecterait une erreur ou un problème.</p>
<p>Quand un script plante et génère une réponse "500 Server Error", sa
réponse peut être remplacée par un message plus convivial, ou par une
redirection vers une autre URL (locale, ou sur un autre serveur).</p>
</summary>
<section id="behavior">
<title>Fonctionnement</title>
<section>
<title>Fonctionnement antérieur</title>
<p>NCSA httpd 1.3 renvoyait un message d'erreur insipide qui ne
présentait le plus souvent aucun sens ni à l'utilisateur, ni
dans les journaux d'enregistrement sur des symptômes causant
le plantage.</p>
</section>
<section>
<title>Fonctionnement des versions plus récentes</title>
<p>Le serveur peut être paramétré pour&nbsp;:</p>
<ol>
<li>Afficher un autre message que celui codé dans NCSA, ou bien</li>
<li>procéder à une redirection sur une URL locale, ou bien</li>
<li>procéder à une redirection vers un autre serveur.</li>
</ol>
<p>La redirection vers une autre URL peut être utile, mais seulement
si des informations peuvent être envoyées pour expliquer/enregistrer
l'erreur ou le problème plus clairement.</p>
<p>Pour y parvenir, Apache définit de nouvelles variables
d'environnement CGI&nbsp;:</p>
<example>
REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap,
image/jpeg<br />
REDIRECT_HTTP_USER_AGENT=Mozilla/1.1b2 (X11; I; HP-UX A.09.05
9000/712)<br />
REDIRECT_PATH=.:/bin:/usr/local/bin:/etc<br />
REDIRECT_QUERY_STRING=<br />
REDIRECT_REMOTE_ADDR=121.345.78.123<br />
REDIRECT_REMOTE_HOST=ooh.ahhh.com<br />
REDIRECT_SERVER_NAME=crash.bang.edu<br />
REDIRECT_SERVER_PORT=80<br />
REDIRECT_SERVER_SOFTWARE=Apache/0.8.15<br />
REDIRECT_URL=/cgi-bin/buggy.pl
</example>
<p>Notez que le préfixe <code>REDIRECT_</code> est présent pour toutes
ces variables d'environnement.</p>
<p>Au minimum, <code>REDIRECT_URL</code> et
<code>REDIRECT_QUERY_STRING</code> seront passées à la nouvelle
URL (en supposant qu'il s'agisse d'un script CGI ou d'un
include CGI). Les autres variables ne sont définies que si
elles existaient avant l'apparition du problème ou de l'erreur.
<strong>Aucune</strong> de ces variables ne sera
définie si votre directive <directive module="core">ErrorDocument</directive>
entraîne une redirection vers un serveur <em>externe</em>&nbsp;;
tout ce qui commence par <code>http:</code> est considéré comme
une redirection externe, y compris si cela pointe vers le
serveur local.</p>
</section>
</section>
<section id="configuration">
<title>Configuration</title>
<p>Il est possible d'utiliser la directive
<directive module="core">ErrorDocument</directive> dans les fichiers
.htaccess si <directive module="core">AllowOverride</directive> est
paramétrée pour le permettre.</p>
<p>Voici quelques exemples&nbsp;:</p>
<example>
ErrorDocument 500 /cgi-bin/crash-recover <br />
ErrorDocument 500 "Sorry, our script crashed. Oh dear" <br />
ErrorDocument 500 http://xxx/ <br />
ErrorDocument 404 /Lame_excuses/not_found.html <br />
ErrorDocument 401 /Subscription/how_to_subscribe.html
</example>
<p>La syntaxe à utiliser est&nbsp;:</p>
<example>
ErrorDocument &lt;code-à-3-chiffres&gt; &lt;action&gt;
</example>
<p>où l'action peut désigner&nbsp;:</p>
<ol>
<li>Un message à afficher. Le message doit être précédé par
des guillemets ("). Tout ce qui suit ces guillemets est affiché.
<em>Notez que le préfixe (") n'est pas affiché.</em></li>
<li>Une URL vers un serveur externe, vers lequel la redirection
sera effectuée.</li>
<li>Une URL locale vers laquelle la redirection sera effectuée.</li>
</ol>
</section>
<section id="custom">
<title>Messages d'Erreurs Personnalisés et Redirections</title>
<p>Le fonctionnement d'Apache vis-à-vis des redirections a été
modifié afin que les nouvelles variables d'environnement soient
disponibles pour un script ou un server-include.</p>
<section>
<title>Fonctionnement antérieur</title>
<p>Les variables CGI standard étaient passées au script sur
lequel pointe la redirection. Aucune indication sur la
provenance de la redirection n'était fournie.</p>
</section>
<section>
<title>Fonctionnement pour les nouvelles versions</title>
<p>Une série de nouvelles variables d'environnement est
initialisée pour être passée au script sur lequel pointe
la redirection. Chacune de ces variables est munie du préfixe
<code>REDIRECT_</code>. Les variables d'environnement
<code>REDIRECT_</code> sont créées à partir des variables
d'environnement "normales", telles qu'existant avant la
redirection, mais simplement renommées au moyen du préfixe
<code>REDIRECT_</code>&nbsp;; ainsi par exemple <code>HTTP_USER_AGENT</code>
devient <code>REDIRECT_HTTP_USER_AGENT</code>. En plus de ces
nouvelles variables, Apache définit <code>REDIRECT_URL</code>
et <code>REDIRECT_status</code> pour aider le script à
comprendre d'où il a été appelé. L'URL d'origine et l'URL
redirigée sont toutes deux ajoutées dans le journal "access".</p>
<p>Si <code>ErrorDocument</code> précise une redirection
locale vers un script CGI, ce script devrait inclure un
champ "<code>Status:</code>" dans son en-tête de transmission
afin d'assurer que le client reçoive bien le code d'erreur et
puisse comprendre ce qui l'a causé. Par exemple, un script
Perl ErrorDocument pourrait inclure quelque chose comme&nbsp;:</p>
<example>
... <br />
print "Content-type: text/html\n"; <br />
printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; <br />
...
</example>
<p>Un script dédié à la gestion d'une erreur donnée,
telle que <code>404&nbsp;Not&nbsp;Found</code>, peut bien sûr
utiliser le code spécifique d'erreur et le texte associé.</p>
<p>Notez que le script <em>doit</em> envoyer l'en-tête
<code>Status:</code> appropriée (comme par exemple
<code>302&nbsp;Found</code>), si la réponse contient un en-tête
<code>Location:</code> (pour générer la redirection coté client).
Sans cet en-tête <code>Status:</code>, <code>Location:</code> n'aura
pas d'effet.</p>
</section>
</section>
</manualpage>