Que signifie une erreur 500 Internal Server Error et qui en est responsable

Une erreur 500 Internal Server Error est le serveur qui exécute le site admettant que quelque chose s’est mal passé dans son propre code, et qu’il ne peut pas vous montrer la page à cause de cela. Pas « la page n’existe pas », pas « vous n’êtes pas autorisé », pas « revenez plus tard » - juste un honnête et peu utile « quelque chose s’est cassé ici, et ce n’était pas de votre faute ».

Le mot important à noter est interne. C’est le serveur qui parle de lui-même, pas d’un réseau, d’une permission ou de quelque chose que vous avez fait. Il a exécuté votre demande, a rencontré une erreur qu’il ne savait pas comment gérer, et la seule chose honnête à dire était 500. C’est pourquoi le message est si vague : le serveur ne cache pas les détails pour être difficile, il refuse de révéler ses propres internals à un étranger.

Pourquoi cela ne vous dit rien

Une erreur 500 est l’erreur la plus générique du web à dessein. Quand une application échoue d’une manière qu’elle n’avait pas anticipée - une exception que personne n’a capturée, une requête qui a échoué, une valeur null où un objet était attendu - la chose sûre à montrer au monde extérieur est un mur vide. Les détails de ce qui s’est cassé, la pile d’appels, le numéro de ligne, la requête qui a échoué, tout cela reste sur le serveur, dans un journal, où seules les personnes qui gèrent le site peuvent le lire.

L’erreur 500 que vous voyez et la raison pour laquelle elle s’est produite vivent donc dans deux endroits différents. Le navigateur a le code ; le serveur a la cause. Cet écart est toute la difficulté d’une erreur 500, et c’est pourquoi « J’ai reçu une 500 » est un rapport qui dit presque rien à un développeur en lui-même.

Erreur 500 par rapport à 502 et 504, qui se ressemblent de l’extérieur

Ces trois codes appartiennent à la famille du serveur « quelque chose s’est mal passé de notre côté », et les distinguer pointe vers des causes très différentes.

500 Internal Server Error

L'application s'est exécutée et son propre code a échoué - une exception non gérée, un crash dans la requête. Le serveur a répondu ; la réponse était une erreur qu'il a faite lui-même

502 Bad Gateway

Un serveur frontal a reçu une réponse inutilisable de l'application derrière lui - crash, refus, malformée. L'échec se situe entre deux serveurs

504 Gateway Timeout

L'application n'a pas répondu du tout à temps. Le serveur frontal a abandonné l'attente

Sommairement : une erreur 500 est l’application qui échoue pendant qu’elle s’exécute, une 502 est un proxy qui échoue à obtenir une bonne réponse de la part de celle-ci, et une 504 est l’application qui est trop lente pour répondre. Si vous avez reçu une 500, le code s’est exécuté et s’est cassé ; si vous avez reçu une 502 ou 504, il n’a souvent jamais fini de s’exécuter du tout. Cette distinction est la première chose qui vaut la peine d’être connue, car elle décide si vous regardez dans les journaux d’application ou dans la plomberie en face d’eux.

Si vous êtes visiteur

Rechargez une fois, car un bon nombre d’erreurs 500 sont un seul mauvais moment - une requête qui a frappé une course, une requête qui a expiré lors d’une rafale - et la tentative suivante atterrit quelque part de sain. Si elle s’efface, il n’y a rien à poursuivre.

Si elle persiste, la faute est du côté du site, et il n’y a réellement rien dans votre navigateur qui atteigne un bug dans leur code. Effacer votre cache, essayer en incognito, changer de navigateur - rien de tout cela ne touche le serveur, et chacun est une demi-heure courante passée à traiter une 500 comme si c’était un problème que vous pouviez résoudre de votre siège. La seule chose utile que vous puissiez faire est de les en informer, avec suffisamment de détails pour qu’ils trouvent la ligne correspondante dans leur journal : ce que vous faisiez et à peu près quand.

Si c’est votre site

Une erreur 500 signifie que votre code a levé quelque chose qu’il n’a pas géré, donc la question est seulement quoi, et la réponse se trouve dans vos journaux plutôt que dans la réponse que l’utilisateur a vue. Quelques causes représentent la plupart d’entre elles.

Une exception non gérée dans la requête. De loin la plus courante. Une méthode appelée sur une valeur nil, une clé qui n’était pas là, un type qui n’était pas ce que le code supposait. La requête a atteint votre code, votre code a levé, et rien ne l’a capturé. Votre journal d’application a la pile d’appels ; la 500 de l’utilisateur ne l’a pas.

Un appel à la base de données qui a échoué. Une requête contre une colonne qui a été renommée, un pool de connexions épuisé sous la charge, une migration qui s’est exécutée sur un serveur et pas un autre. Ils arrivent souvent par rafales, car ils suivent la charge ou un déploiement plutôt qu’une seule entrée.

Un problème de configuration ou d’environnement. Une variable d’environnement manquante, un secret qui n’a pas été défini, un service que l’application s’attend à atteindre et ne peut pas. Ce sont ceux qui transforment chaque requête en 500 à la fois, généralement juste après un déploiement ou un changement d’infrastructure, et ils semblent alarmants précisément parce que rien dans le code n’a changé - c’est le terrain sous-jacent qui a changé.

Un mauvais déploiement. Un nouveau code qui lève sur un chemin que les tests n’ont pas couvert, ou qui démarre contre un schéma qui n’existe pas encore. Si les 500 ont commencé lors d’une version, c’est le premier endroit à regarder, et un retour en arrière est plus rapide qu’un diagnostic.

La raison pour laquelle une 500 est si difficile à chasser après coup

L’erreur que l’utilisateur a vue ne porte aucune des causes, donc une 500 rapportée une heure plus tard, de mémoire, est pratiquement inutile : vous avez un code générique et un moment approximatif, et vous cherchez dans un journal une aiguille que vous ne pouvez que décrire comme « vers trois heures ». La pile d’appels qui aurait nommé le bug se trouve dans une ligne de journal que personne n’a capturée en fonction de la requête qui l’a produite.

Ce qui ferme rapidement une 500 est la requête qui l’a causée, son moment exact, et ce que la personne faisait - capturé pendant que c’est arrivé, afin que vous puissiez la faire correspondre à la seule ligne de journal qui contient la véritable erreur. C’est la différence entre un bug que vous trouvez en une minute et un journal que vous faites défiler pendant un après-midi.

Le journal réseau contient la requête qui a échoué avec sa 500 et le moment exact où elle s’est produite, afin que quiconque ramasse le rapport puisse l’aligner avec le journal du serveur et lire la vraie erreur - plutôt que de reproduire le tout d’abord pour découvrir ce qu’un code générique cachait.

En un paragraphe

Une erreur 500 Internal Server Error signifie que l’application a exécuté votre requête et que son propre code a échoué d’une manière qu’il n’a pas gérée, donc il a montré la seule réponse sûre et générique qu’il avait - ce qui est ce qui la rend différente d’une 502, où un proxy n’a pas pu obtenir une bonne réponse de l’application, et d’une 504, où l’application était trop lente pour répondre du tout. Si vous êtes visiteur, rechargez une fois puis supposez que c’est de leur côté. Si c’est le vôtre, la cause est dans vos journaux, pas la réponse : soupçonnez une exception non gérée, une requête qui a échoué, une configuration manquante, ou le dernier déploiement - et capturez la requête qui a échoué pendant que vous l’avez, car une 500 ne vous dit rien en elle-même.