Les codes (statuts) HTTP à connaître

En tant que développeurs web, nous fournissons des services au travers du web, et la plus part du temps au travers du protocole HTTP.

Dans les meilleurs des cas nous retournons un statut « 200 OK », indiquant que tout s’est bien passé, accompagné d’une page Web à l’attention de l’internaute. Malheureusement, il n’est pas toujours possible de répondre aussi favorablement à l’utilisateur et nous lui affichons alors des retours d’erreur… mais sans code HTTP pertinent correspondant.

Cet article à pour but de lister les codes HTTP indispensables (et non une liste exhaustive) que tout développeur web (PHP ou pas) devrait connaître… et encore plus lors du développement de services REST !

Commençons par les catégories

On peut segmenter les familles de code en 5 catégories :

  • Informations (100-199)
  • Succès (200-299)
  • Redirection (300-399)
  • Erreur Client (400-499)
  • Erreur Serveur (500-599)

Généralement, nous nous servirons de 4 familles (2XX à 5XX).

Les succès

  • 200 – OK : La requête demandée a été traitée avec succès. C’est ce qui est retourné 90% du temps, le comportement normal de l’application qui affiche un contenu correct.

Les redirections

  • 301 – Moved Permanently : La ressource demandée a définitivement été déplacée à une autre URL. Le client devrait ainsi mettre à jour l’emplacement de cette ressource pour ne plus la rechercher à l’emplacement courant.
  • 302 – Found (HTTP 1.0) : La ressource demandée est accessible temporairement depuis une autre URL. En ce sens, la redirection étant temporaire, le client devrait continuer de solliciter la ressource depuis l’URL qu’il a demandé.
  • 303 – See Other (HTTP 1.1) : La réponse pour la ressource demandée est accessible à une autre URL. L’adresse qu’il faut continuer de solliciter pour la ressource est bien celle demandée par le client, mais la réponse est disponible ailleurs, par l’intermédiaire d’une requête GET. Cette redirection est typiquement recommandée après un POST, si votre site veut indiquer la page de réponse à un autre endroit (RFC 2616).
  • 307 – Temporary Redirect (HTTP 1.1) : La ressource demandée est accessible temporairement depuis une autre URL. Pour accéder à cette URL temporaire, le client DOIT soumettre sa requête avec la même méthode qu’il l’a déjà fait (refaire une requête POST si la demande initiale était en POST, PUT pour du PUT, …). A l’avenir, la redirection étant temporaire, le client devrait continuer de solliciter la ressource à l’URL demandée initialement.

302, 303 et 307, quelles différences ?

Le code 302, à son origine, aurait du entraîner les clients à conserver la méthode d’interrogation utilisée au départ (au même titre que le code 307). Dans les faits, certains outils répandus faisaient cette redirection par l’intermédiaire d’une requête de type GET, quel que soit la méthode originelle d’interrogation (POST PUT ou DELETE).

Les codes 303 et 307 sont donc apparus pour lever l’ambiguïté et demander au client de conserver (307) ou pas (303) la méthode d’interrogation initiale de la ressource à son emplacement temporaire.

Les erreurs coté client

  • 400 – Bad Request : La syntaxe de la requête semble incorrecte. Pour ma part, je l’utilise par exemple en cas de paramètre (GET ou POST) manquant ou incorrect, comme le fait aussi OAuth.
  • 401 – Unauthorized : L’erreur 401 (je ne sais pas qui vous êtes) indique qu’une authentification est nécessaire afin d’accéder à la ressource, et le client est invité à s’authentifier (correctement) s’il veut accéder à la ressource.
  • 403 – Forbidden : (Je sais qui vous êtes, vous ne pouvez pas) On indique, comme pour l’erreur 401, qu’une autorisation est nécessaire pour pouvoir accéder à la ressource, et que le niveau de droit courant n’est pas suffisant.
  • 404 – Not Found : La ressource est introuvable.
  • 410 – Gone : Petite soeur de la page 404, on indique ici que la ressource n’est « plus » disponible à cette adresse (définitivement ou non) sans que le serveur soit en mesure de donner une nouvelle adresse.
  • 405 – Method Not Allowed : Le client tente d’accéder à la ressource via une méthode (GET / POST / PUT / DELETE) non autorisée pour cette dernière. La réponse devrait contenir la liste des méthodes autorisées pour la ressource.

Erreurs serveurs

  • 500 – Internal Server Error : ça plante, mais pourquoi… ?
  • 501 – Not Implemented : Le serveur ne sait pas traiter la demande.
  • 503 – Service Unavailable : Le site est en maintenance ou indisponible de façon temporaire. En d’autres termes, vous indiquez au client de ne surtout pas vous oublier, vous allez revenir.

Ce qu’il faut retenir de cette liste ?

La seule chose qu’il faut retenir de cette liste : N’utilisez jamais un code http 200 OK pour les cas (courants) suivants :

  • Le site est en maintenance, merci de revenir plus tard (503)
  • Désolé, vous ne pouvez pas consulter cet article (401 / 403)
  • Erreur, il manque le paramètre X ou Y (400)
  • Désolé, cet article a été supprimé (410)

N’oublions pas d’ailleurs que dans le contexte de sites publics, tout ce qui répond « 200 OK » signifie « Moteur de recherche, indexe ce contenu, il est correct et destiné à l’utilisateur ».

D’autres codes vous semblent indispensables à connaître ? N’hésitez pas à les ajouter dans les commentaires.

  1. Un minimum en effet pour monter une archi REST.

  2. A noter : selon le standard, dans le cas de 401 il FAUT envoyer des en-têtes WWW-Authenticate pour faire une authentifcation HTTP (cf. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2). Du coup, on ne peut pas l’utiliser pour indiquer une authentification par formulaire.

  3. Merci de la précision.

    J’ai essayé de reformuler 401 / 403 pour lever l’ambiguïté.

  4. Le rappel est toujours bon.
    Maintenant, sommes nous libre d’utiliser les classes non utilisées comme bon nous semble (par exemple utiliser les 51x ou+ pour ses propres codes d’erreurs) ?

  5. Il me semble qu’il est complètement autorisé (1) de créer ses propres codes. La RFC cite : Les codes de statut HTTP sont extensibles. (…) Il est toutefois indispensable que la classe du statut soit correcte (note : le premier digit). Les applications devront traiter un code non compris comme l’équivalent x00 de la classe correspondante. Les réponses non reconnues ne devront pas être mises en cache.

    J’avoue toutefois que je n’ai, pour ma part, jamais eu le besoin d’étendre un code HTTP et que je préfère souvent ajouter un détail dans le corps de la requête en elle même.

    Dans le cadre de services REST, une réponse JSON avec la raison du 404 par exemple.

    (1) RFC http://tools.ietf.org/html/rfc2616#section-6.1.1

  6. Pour des web-services on s’en est souvent servi afin d’ordonner les erreurs applicatives. Mais je pense que cela dépend des affinités des développeurs.

  7. Mon avis perso : HTTP = la base. :grin:

  8. Il manque la 418 !! qu’elle honte ;)

Laisser un commentaire


NOTE - Vous pouvez utiliser les éléments et attributs HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>