Utilisation des code de status HTTP

[Forban]

Bonjour,

Je poste aujourd'hui afin d'obtenir des réponses à une question que je me pose depuis peu : quand faut-il utiliser les codes de status HTTP ?

En effet, il est tout à fait possible, lorsqu'une page n'existe pas, d'afficher une page 'Erreur 404' sans pour autant retourner un code 404.
Et c'est le cas pour tous ces codes, c'est pourquoi je me pose la question :
-Est-il indispensable d'utiliser les codes de status HTTP ?
-Si oui, pourquoi et comment savoir quand le faire ? (il existe un bon nombre de codes..)
-Si non, est-ce une bonne pratique ? Pourquoi ?

Merci par avance.

Bonne fin de semaine à tous.

[Xenos]

Salut,

pour ma part (quand bien même me traiterait-on de psycho-rigide), je pense qu'il faut toujours setter les code de retour HTTP, car ce sont eux qui, selon le standard web, définissent ce que "représente" la page (aka "est ce que ma commande a bien marché? si elle a foiré pourquoi?").

Mettre le bon statut permettra alors de gérer correctement ces erreurs dans le code client, et d'être compris par les autres clients (moteur de recherche, autres développeurs utilisant ton API, etc).

Par exemple, si tu retournes un code 200 au lieu du 404, et que tu écris dans la page "Page non trouvée, 404", alors pour google (ou tout autre moteur de recherche), ce sera une page valide: elle sera indexée, t'auras 0 retour de la part du moteur (ou d'autre système) pour te dire "cette page a fichu le camp!" et tu pourrais même être pénalisé pour "duplicated content" (= cette fausse page 404 revient souvent, donc ton site a beaucoup de pages en doublon, donc tu essaies peut-être de blouzer le moteur de recherche).

Pour les navigateurs, cela pourrait également être important: cela permet au navigateur de savoir s'il peut/devrait recharger la page (si on répond un "temporarily not available", peut-être que le navigateur va recharger la page au bout de 1 minute, ou qu'un plugin le fera).

Pour tes outils de stats, c'est aussi important: dans les stats Urchin d'OVH, tu as le nb de codes 5xx et 4xx, pour savoir si tu as des erreurs ou non. Idem dans les log Apache.

Donc, oui, c'est important de retourner les bons status HTTP, ça (te) sera toujours utile un jour. Et il en existe des brouettes, donc tu as surement déjà le code qui matche ton erreur (rien n'interdit d'en rajouter 1 ou 2 custom si besoin).


PS: en pièce jointe, je t'ai mis les enums dont je me sert pours les codes http, et les headers de requete/réponse (puis quelques enums de plus)

[Forban]

Merci pour ton retour d'expérience.

Je me pose tout de même une question : faut-il retourner un code d'erreur 405 (method not allowed) si jamais un utilisateur souhaite directement accéder à une page qui devrait accueillir une requête POST ou n'ai-je pas bien saisi l'application de tels codes ? (par exemple si l'on traite un formulaire sur une page "traitement.php" qui n'aurait pour but que le traitement d'un formulaire, doit-on retourner 405 si l'utilisateur tape directement cette adresse dans son navigateur ?)

Merci pour le fichier enums, je vais voir ça, c'est super sympa.

[Xenos]

Si, tu as bien saisis Si une requête GET (ou autre verbe: on peut mettre ce qu'on veut donc une requete NESGENOUX est possible aussi) est faite sur une URL qui ne gère pas ce verbe, alors l'URL devrait retourner un code 405. Après, l'URL peut aussi retourner un contenu à sa réponse (un "body") qui peut être une page HTML (ou autre format, suivant ce que le client a demandé via sont header "Accept") décrivant plus en avant l'erreur ("This only expects POST request").

Pour ECLERD par exemple (release prévue dans la semaine), si la page n'est pas trouvée, le jeu renvoie une 404, et le contenu de la page dépend du header Accept du client (si "Accept:text/html", alors ce sera une apge classique "Cette page n'existe pas"; si "Accept: application/json" alors je crois que le contenu est un objet vide "{}", etc). Même principe pour une erreur 500 (si le serveur a planté, normalement dans ce genre de cas, tu as une exception qui est "throw", et un "catch (Throwable $ex)" global qui log cette exception, et qui va ensuite retourner un code HTTP 500 avec une page disant "le serveur a planté"). Même principe avec une 401 (quand on essaie d'accéder à une page nécessitant d'être connecté alors qu'on ne l'est pas déjà) ou 403 (quand on veut accéder à une page et qu'on n'a pas le droit, même si on se connectait). Ca vaut aussi pour les 301, 302, 307, 308 (redirections une fois le formulaire traité, ou redirection parce que la page a bougée)

[Forban]

D'accord, c'est déjà beaucoup plus clair pour moi, merci pour l'explication.
Dans l'exemple de ton jeu, je suppose que :
Dès qu'un utilisateur souhaite accéder à une page nécessitant d'être connecté, tu renvoies un code d'erreur si jamais la session n'existe pas ?

C'est vraiment dommage que ce genre de choses ne soit pas enseigné durant les études. (en tout cas, ça ne l'est pas dans ma licence ^^)

[Xenos]

(avis personnel en approche: put*** l'enseignement de l'informatique à l'école est une grosse grosse chiasse sans rigueur ni méthode, qui se contente de pousser les futurs ingénieurs [parce que oui, ce sont des ingénieurs avant tout] à juste pisser du code ou à aller récupéré les tonnes de code pissées par d'autres inutilement. Fin du vent)

C'est cela, si la page a besoin que l'utilisateur soit connecté, son code utilise:

Code PHP :

<?php 

$config->getSessionManager()->mustBeLoggedIn() 

[Forban]

Wow, en effet Xenos, j'avoue que tu me perds un peu pour le coup. ^^

[Xenos]

J'essayerai peut-être d'expliquer tout ça plus posément et de façon plus structurée dans un article. D'ici là, ECLERD est déjà sorti ( https://eclerd.com ) donc tu peux éventuellement gratouiller dedans (via le panneau réseau de la console du navigateur par exemple) pour voir comment les statuts HTTP sont utilisés.

Le traitement de ces statuts est dans form.js; les codes HTTP permettent alors de discriminer ce qu'il se passe de façon standard, aka "code 404" tout dev sait ce que ça signifie, alors que {row:{message:"Pas trouvé!"}} ne sera pas compréhensible par tous les humains, encore moins par toutes les machines [c'est l'intérêt de tout standard, que ce soit HTTP, CSS, HTML, etc]. Un code plus spécifique au jeu "if (content['row'] && ...)" permet ensuite de savoir si je sais traiter le soucis (t'as demandé à envoyer un message à un joueur qui n'est pas dans le jeu, donc, je te le dis en affichant le message renvoyé par le jeu), ou si je ne sais pas le traiter (j'ai mal codé le jeu et j'ai demandé une page qui n'existe pas)

Mais ça vaut pour tout autre site web au fond: le but d'utiliser (les codes) standards, c'est d'être compris par tout le monde et de parler la même langue