HTTP-Error 500 : d’où vient le problème ?

L‘erreur « Internal Server Error » peut se produire lorsque la requête est traitée par le serveur Web. Ce groupe de codes de statut comprend tout ce qui se passe in­vo­lon­tai­re­ment sur le serveur, empêchant l’affichage du site. L’erreur server 500 se produit pro­ba­ble­ment car une erreur s’est produite lors de la con­fi­gu­ra­tion du serveur Web. Voici une sélection de sources typiques d’erreurs :

• Erreur de per­mis­sion : les au­to­ri­sa­tions des fichiers et des dossiers prin­ci­paux ne sont pas définies cor­rec­te­ment

• PHP-Timeout : le script tente d’accéder à une ressource externe et éprouve un délai d’attente

• Code incorrect dans .htaccess : la structure dans un fichier .htaccess peut être in­cor­recte

• Erreur dans la syntaxe ou du code dans les scripts CGI/Perl : dans certains cas, les scripts sont in­cor­rects. Les chemins peuvent notamment être mal situés.

• PHP-Memory-Limit : un processus dépasse la mémoire et ne peut pas être exécuté cor­rec­te­ment

Avec des pages WordPress ou d’autres systèmes de gestion de contenu, l’ins­tal­la­tion d’une extension dé­fec­tueuse ou in­com­pa­tible peut aussi être la cause. Plugins et thèmes, en par­ti­cu­lier de four­nis­seurs tiers, peuvent affecter l‘in­té­gra­lité du site.

Les visiteurs de votre site Web ne voient plus le contenu, mais seulement l’erreur du serveur 500 ? En tant qu’ex­ploi­tant de site Internet, vous devriez di­rec­te­ment aborder le problème, car ce ne sera pas seulement énervant pour les visiteurs de votre site, Google pourrait aussi décider de vous pénaliser au niveau du ré­fé­ren­ce­ment. Avant d’effectuer la moindre action en tant que Webmaster, vérifiez d’abord si votre serveur fonc­tionne toujours. Sinon, un contact rapide avec votre four­nis­seur d’hé­ber­ge­ment est né­ces­saire.

S’il y a une erreur interne, regardez d’abord les fichiers log : pour les serveurs Linux, la collecte des messages d’erreur se trouve sous /var/log/httpd/error_log. Il est pour cela utile de recharger le site Web pour re­pro­duire l’erreur HTTP 500, tout en observant la création du fichier Log. Vous pouvez ainsi trouver la source de l’erreur assez ra­pi­de­ment. Dans de nombreux cas, les plugins in­cor­rec­te­ment pro­gram­més ou in­com­pa­tibles four­nis­sent des messages d’erreur.

L’erreur peut également se produire si vous n’avez pas défini cor­rec­te­ment les au­to­ri­sa­tions pour les fichiers im­por­tants. Il existe gé­né­ra­le­ment trois types de droits :

• Lire (r pour read)
• Ecrire (w pour write)
• Exécuter (x pour execute)

Ces au­to­ri­sa­tions peuvent être at­tri­buées à trois types d’uti­li­sa­teurs dif­fé­rents :

• Pro­prié­taire du fichier
• Groupe d’uti­li­sa­teurs
• Tous les autres

Les droits sont indiqués soit par les abré­via­tions r, w et x soit par les valeurs nu­mé­riques cor­res­pon­dantes : 4 pour lire, 2 pour écrire et 1 pour exécuter. Ils sont ajoutés pour chaque type d’uti­li­sa­teur et sont donnés l’un après l’autre : rwxr-xr-x (rwx pour le pro­prié­taire, r-x pour le groupe et  r-x pour tous les autres) ou 755. Cette con­fi­gu­ra­tion (aussi 755) devrait être le pa­ra­mé­trage standard. Si l’af­fec­ta­tion des droits est définie dif­fé­rem­ment, l’erreur peut se produire. Vous pouvez modifier ceci avec une commande :

Si cette mo­di­fi­ca­tion ne change pas le problème, vous pouvez également partager tous les droits pour chaque groupe à des fins de test :

Utilisez ce paramètre uni­que­ment pour localiser le problème. Cela permet à tout uti­li­sa­teur de réécrire le fichier, ce qui est na­tu­rel­le­ment un risque pour la sécurité.

Vérifiez ensuite si vos scripts fonc­tion­nent cor­rec­te­ment (sauf si la dis­tri­bu­tion des droits a produit le message d’erreur). Parfois, des erreurs se pro­dui­sent car les fichiers scripts ont été déplacés, renommés ou supprimés. Vérifiez aussi le fichier .htaccess car une erreur de syntaxe, aussi petite soit-elle, peut générer une erreur interne au niveau du serveur. Une erreur également courante est la mise en forme in­cor­recte du fichier .htaccess. Ce dernier doit être créé au format ASCII ou ANSI, mais comme Unicode. Ecrivez par con­sé­quent le fichier dans un éditeur de texte tel que Notepad, Notepadd++ ou Sublime Text, et pas dans un programme de trai­te­ment de texte tel que Microsoft Word. Afin de tester si le fichier est res­pon­sable de l’erreur, vous pouvez le renommer et le recharger tem­po­rai­re­ment. Le serveur n’accédera pas à .htaccess pendant le char­ge­ment du site. Si le message d’erreur ne se produit plus, vous pouvez réparer le fichier ou en créer un nouveau.

Enfin, un délai d’attente peut également conduire au message d’erreur. Dans ce cas, ce n’est pas une erreur du serveur Web, mais plutôt une connexion in­ter­rom­pue à une source externe. Les scripts PHP sur votre site sont-ils con­fi­gu­rés pour vous permettre d‘accéder aux res­sources d’autres serveurs ? La ressource peut ne pas être dis­po­nible, ou la com­mu­ni­ca­tion du serveur est perturbée pour une autre raison. Une pos­si­bi­lité pour exclure cette source d’erreur est de rendre votre page in­dé­pen­dante des res­sources externes. Si cela n’est pas possible, vous pouvez augmenter le délai de votre script. Il est en outre pertinent d’inclure une gestion efficace des erreurs, de sorte que les erreurs dans le script PHP puissent être détectées plus ra­pi­de­ment.

La mémoire peut-elle être sur­char­gée ? La limite de mémoire est utilisée pour dé­ter­mi­ner la quantité de mémoire qu’un processus peut prendre. Si plus de RAM est né­ces­saire, une erreur interne du serveur peut en résulter. Vous pouvez définir la limite comme une solution tem­po­raire. Pour ce faire, ajouter une commande au php.ini selon ce modèle :

Dans cet exemple, vous mettez 512 Mo de mémoire à dis­po­si­tion. Gardez toutefois à l’esprit que votre four­nis­seur d’hé­ber­ge­ment vous offre une limite de script PHP spé­ci­fique dans l’offre réservée. Si vous entrez une valeur plus élevée, le serveur Web l’ignorera. Le réglage de la limite ne peut être qu’une solution de tran­si­tion : une fois que votre page réap­pa­raît, vous devriez re­cher­cher le motif du fort besoin en RAM. Il est fort probable que l’erreur se trouve dans le code de votre site.

Si parmi les méthodes ci-dessus vous ne parvenez pas à trouver une solution, il est judicieux de contacter votre four­nis­seur d’hé­ber­ge­ment. Avant de pouvoir vérifier l’état des serveurs : de nombreux four­nis­seurs de services d’hé­ber­ge­ment annoncent l’état de leurs serveurs via une page d’état ou informent les uti­li­sa­teurs via les réseaux sociaux en cas de problème.

Si des problèmes de serveur sont déjà connus, vous devez faire preuve de patience : il ne vous reste plus qu’à attendre que l’équipe IT de l’hébergeur corrige le bug. Mais même si aucun problème avec les serveurs n’est connu, un contact avec l’as­sis­tance peut être utile. Faites-leur savoir quelles mesures vous avez déjà prises. Vous pouvez ainsi vous faire aider ra­pi­de­ment.

En tant que visiteur d’un site Web, vous ne pouvez en principe pas faire grand-chose si vous ren­con­trez une erreur de serveur interne. Le serveur Web sur lequel se trouve le site Web ciblé renvoie à une con­fi­gu­ra­tion dé­fec­tueuse. Cela signifie qu’il n’y a pas d’erreur dans les pa­ra­mètres de votre PC ou de la connexion réseau. Par con­sé­quent, en tant qu’in­ter­naute, la solution la plus simple est de recharger la page ul­té­rieu­re­ment. D’une part, il se peut que le Webmaster ait déjà corrigé l’erreur. Ceci est par­ti­cu­liè­re­ment probable avec de gros four­nis­seurs. En revanche, il est aussi probable que vous sou­hai­tiez accéder à un contenu au mauvais moment. Si vous arrivez au moment où le service redémarre, le message d’erreur s’affiche, bien que tout se passe selon le plan.