Lire les journaux pour diagnostiquer 403 et 500

Une page qui renvoie 403 ou 500 ne vous dit pas, à elle seule, ce qui a échoué. Apache consigne des informations distinctes sur les requêtes reçues et sur les problèmes rencontrés pendant leur traitement. Dans cette leçon, vous apprendrez à repérer ces informations et à les utiliser pour cibler votre diagnostic, sans modifier la configuration globale.

Deux journaux, deux usages

Le journal d’accès enregistre les requêtes traitées et leur résultat HTTP. Il permet notamment de confirmer qu’une requête a atteint le bon hôte et d’identifier son chemin, son code de réponse et, selon le format configuré, l’adresse du client. Le journal d’erreurs contient des messages émis par Apache lorsqu’il rencontre un problème : il peut préciser le fichier concerné, la directive en cause ou l’étape qui a échoué.

Les fichiers des hôtes du projet sont séparés. Pour le site principal, commencez par le journal d’erreurs déjà utilisé dans le parcours, /var/log/apache2/application-error.log, puis consultez le journal d’accès associé à cet hôte. Pour api.example.test, lisez les journaux propres à son hôte virtuel ; les chemins exacts dépendent des directives ErrorLog et CustomLog de ses fichiers de configuration. Les chemins Apache diffèrent aussi selon la distribution.

Interpréter une réponse 403

Le code 403 Forbidden indique qu’Apache a refusé l’accès à la ressource. Le fichier peut exister, mais le processus Apache ne peut pas le lire ou ne peut pas traverser un répertoire parent ; une règle d’accès peut aussi interdire la requête. Le code seul ne permet pas de choisir entre ces causes : cherchez dans le journal d’erreurs un message correspondant au même moment et au même chemin.

[Mon Jun 17 10:14:02.123456 2024] [core:error] [pid 1842] (13)Permission denied: [client 192.0.2.24:51230] AH00132: file permissions deny server access: /var/www/application/prive.html

Dans cet exemple, Permission denied et le chemin sous /var/www/application orientent vers un problème de droits sur le fichier ou l’un des répertoires parents. Vérifiez les permissions de lecture et de traversée selon la méthode vue dans « Définir les permissions nécessaires », sans ouvrir les droits à tous les utilisateurs. Si le message indique plutôt un refus par une règle, examinez la configuration de l’hôte concerné et la ressource demandée.

Interpréter une réponse 500

Le code 500 Internal Server Error signale qu’une erreur côté serveur a empêché le traitement normal de la requête. Dans ce projet, examinez en priorité les messages du journal d’erreurs liés à l’hôte et à l’heure de la réponse ; une faute de syntaxe dans une configuration peut empêcher Apache de la valider ou de la recharger, tandis qu’une règle de réécriture incorrecte peut provoquer un comportement inattendu. Ne déduisez pas la cause du seul code 500 : le message Apache fournit les indices déterminants.

[Mon Jun 17 10:18:41.654321 2024] [core:error] [pid 1842] [client 192.0.2.24:51230] AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error.

Ce message indique une répétition excessive de traitements internes, souvent liée à une règle qui renvoie vers une URL qu’elle traite de nouveau. Comparez le chemin demandé avec les conditions et substitutions de mod_rewrite dans l’hôte concerné. La règle /accueil vers /index.html du site principal a été étudiée dans « Appliquer une règle aux pages du site » ; vérifiez qu’une autre règle ne crée pas de boucle autour de cette ressource.

Corréler la requête et le message

Commencez par noter le nom d’hôte, le chemin demandé et l’heure approximative de l’erreur. Recherchez ensuite cette période dans le journal d’accès pour confirmer le code retourné, puis dans le journal d’erreurs de ce même hôte pour trouver l’explication éventuelle. Les journaux peuvent contenir plusieurs requêtes simultanées : le chemin, l’horodatage et, quand elle est présente, l’adresse du client aident à éviter d’associer un message à la mauvaise visite.

sudo tail -n 50 /var/log/apache2/application-error.log
sudo tail -n 50 /var/log/apache2/application-access.log
sudo tail -f /var/log/apache2/application-error.log

La première commande affiche les derniers messages d’erreur, la deuxième les dernières requêtes d’accès et la troisième suit le journal d’erreurs en temps réel. Remplacez le chemin du journal d’accès par celui effectivement déclaré pour votre hôte. Pour l’API, utilisez les fichiers propres à api.example.test plutôt que de chercher uniquement dans les journaux du site principal.

À retenir

• Le journal d’accès confirme la requête et son code HTTP ; le journal d’erreurs donne des indices sur la cause.
• Un 403 oriente notamment vers les permissions ou une règle d’accès ; un 500 peut signaler un problème de traitement ou de configuration.
• Corrélez nom d’hôte, chemin et heure avant d’interpréter une entrée de journal.
• Consultez les journaux propres à l’hôte virtuel concerné et adaptez les chemins à votre distribution.

Dans la prochaine leçon, vous préparerez le déploiement du site en contrôlant les fichiers et les permissions de son arborescence.