Merci de corriger l'erreur 500

Mais si vous savez, une page un peu comme celle-ci :

Il faut avouer que c'est agaçant... Alors imaginez que vous êtes le propriétaire du site, ni une ni deux, vous faites un mail ou un ticket à votre prestataire en lui disant qu'il est bien gentil mais qu'il corrige cette erreur 500 qui traîne et bien entendu au plus vite. Évidemment, le prestataire va se mettre en 4 pour réussir à corriger le problème. En tout cas chez nous c'est ce qu'on fait, si ce n'est pas le cas avec le vôtre, changez-en !

N'avez vous pas remarqué d'ailleurs que c'est souvent ce code là le problème ? Ce même numéro d'erreur revient régulièrement. Pourtant le développeur avait déjà corrigé l'erreur 500 il y a deux mois... Sauf que ce que vous n'imaginez peut être pas, c'est que ce fameux code 500 que vous pensez significatif n'aide en rien du tout le développeur ou alors si peu.

Des codes dans le protocole

C'est que ce code est générique en fait et pas du tout du fait de votre site. Il est dans le protocole HTTP qui détermine le dialogue entre votre navigateur web et un serveur.

Quand vous tapez une adresse, ou que vous cliquez sur un lien, votre navigateur web va interroger le serveur correspondant pour obtenir une réponse. La réponse c'est souvent le contenu d'une page web, mais ça peut être une image ou une vidéo, ou autre, voire même pas de réponse du tout. Mais dans tous les cas, si votre navigateur obtient une réponse, il va également recevoir du serveur un code d'état HTTP.

Si tout se passe bien, et c'est quand même la majorité des cas, c'est un code 200 que recevra votre navigateur lui indiquant ainsi qu'il a reçu la réponse correcte suite à sa demande. Ce code HTTP permet au navigateur et au serveur de se comprendre, de savoir si tout s'est bien passé ou pas. La liste des codes est normalisée de fait que tout le monde utilise ces références.

Un code en 1xx sera un code de type information et vous en croiserez rarement. Un code en 2xx signifiera un succès dans tous les cas, et même si votre navigateur ne les affiche pas, ce sont les plus courants.

Le serveur va utiliser des codes en 3xx pour indiquer des redirections au navigateur, par exemple quand une page a changé d'adresse, le serveur indique la nouvelle avec un code 302 par exemple et le navigateur web va demander la nouvelle adresse pour finir par afficher la page. Et des redirections vous en croisez sans doute très souvent sans même les remarquer !

404 Not found

Les codes en 4xx servent à indiquer une erreur côté client c'est à dire dans notre cas côté navigateur web. La plus fréquente, c'est la fameuse erreur 404 qui se produit quand vous tapez une URL mais que la page, ou toute autre ressource, n'existe pas ou n'existe plus à cette adresse. On peut du coup associer ce code 404 à un message "Not found" : non trouvé. On considère que l'erreur vient du navigateur puisque c'est bien lui qui fait la demande d'une adresse qui ne correspond à rien.

Mais il y a d'autres codes comme des 401 Unauthorized si vous essayez d'accéder à un document mais qu'il est nécessaire de s'authentifier, voire 403 Forbidden, vous êtes bien authentifié mais vous n'avez pas le droit d'accéder à ce document. Vous verrez peut être même parfois des 400 Bad Request, votre navigateur a fait une requête au serveur web que celui ci ne comprend pas.

500 Internal Server Error

Enfin les codes en 5xx sont des erreurs côté serveur, dont la plus connue est la 500, mais ce n'est pas la seule !
Cette gamme d'erreur est nécessairement la plus visible.

Une 502 Bad Gateway par exemple peut se produire quand pour vous répondre, un serveur doit en solliciter un autre et que ce dernier retourne une erreur. Ça peut être le cas sur certaines infrastructures d'hébergement un peu plus complexe que d'ordinaire.

Vous pouvez rencontrer aussi des 503 Unavailable quand le service n'est pas disponible temporairement voire en maintenance (très utile par exemple lors des migrations de site !).

Et puis, il y a notre fameuse erreur 500 qui est donc une Internal Server Error, c'est à dire que le serveur en voulant vous répondre a lui même rencontré une erreur lorsqu'il a essayé de traiter la demande. Sur la plupart des sites, le contenu de la réponse doit être généré, que ça soit par PHP ou un autre langage, et en cas d'insuccès, le serveur ou l'application elle même va générer un code 500 en retour.

Une question d'affichage

Quand le navigateur reçoit le code HTTP, la plupart du temps il a également en retour une page web qu'il peut afficher, mais pas forcément. Quand il n'a rien, le navigateur va afficher une page qu'il construit lui même pour vous afficher l'erreur.

Par exemple, sous Chrome, ça peut ressembler à ça :

Ça ne donne donc réellement aucune information de plus. Mais un développeur va finir par reconnaître quelques pages qui lui deviendront familières, comme celle du serveur web NGINX :

Ou comme celle que Symfony, notre framework de référence, peut produire par défaut (c'est celle qu'on a vu plus haut) :

Ça donnera donc au développeur web un tout petit début de piste pour savoir si l'erreur est plutôt Symfony ou pas, mais guère plus. Il devra réussir à reproduire l'erreur pour essayer de la comprendre, de trouver le problème et enfin le corriger. Il a sûrement d'ailleurs des logs ou des remontées d'erreurs dans des outils comme Sentry pour l'aider.

Il est néanmoins possible de personnaliser ces pages d'erreur, c'est souvent le cas pour les 404, un peu moins pour les 500. Dans ce cas, vous avez encore moins d'indice pour savoir qui a généré la page d'erreur.

Alors qu'une page 500 de Tomcat, un serveur web pour java ne laisse guère de doute :

Les pages qu'Apache, un serveur web ne sont guère plus réussies :

Quant à Varnish, un serveur très utilisé pour faire du cache, ses pages sont facilement reconnaissable :

Ces pages, vous ne devriez jamais les voir. Mais maintenant quand vous les verrez, j'espère que vous les comprendrez un peu mieux, sans imaginer qu'elles ont une signification au delà de simplement dire... Houston ? Nous avons un problème.