Codes de statut HTTP 400 : découvrir la signification des codes de la série 400

Les codes de statut HTTP 400 jouent un rôle important dans la gestion des interactions entre les clients et les serveurs web. Ces codes signalent des erreurs attribuées aux actions du client, telles que des requêtes mal formulées ou des demandes de ressources non autorisées.

Comprendre ces codes est indispensable pour tout développeur web souhaitant optimiser l’expérience utilisateur et améliorer la robustesse de ses applications. Cet article explore chaque code de la série 400, fournissant des éclairages sur leur signification et des exemples pratiques pour chaque situation.

Quels sont les différents codes de statut HTTP 100 sur le web ?

Les codes de statut HTTP 400 sont utilisés pour signaler des erreurs du côté client. Ils indiquent que le serveur a reçu la requête, mais qu’il ne peut pas ou ne va pas la traiter en raison de quelque chose qui est perçu comme une erreur de la part du client.

Voici une explication détaillée de chacun des principaux codes de statut 400, avec des exemples pertinents pour chacun :

1. 400 Bad Request

Ce code signifie que la requête envoyée au serveur est mal formée et que le serveur ne peut pas la traiter en raison d’une syntaxe incorrecte.

Exemple :

• Un client envoie une requête HTTP avec un formatage incorrect des en-têtes. Le serveur répond par 400 Bad Request pour indiquer que la requête ne peut pas être traitée en l’état.

2. 401 Unauthorized

Ce code est utilisé lorsque l’authentification est requise et a échoué ou n’a pas encore été fournie.

Exemple :

• Un utilisateur tente d’accéder à une page protégée sans fournir des credentials valides. Le serveur renvoie 401 Unauthorized pour demander une authentification.

3. 403 Forbidden

Le serveur a compris la requête, mais refuse de l’autoriser. Contrairement à 401, dans ce cas, l’authentification ne ferait aucune différence.

Exemple :

• Un utilisateur essaie d’accéder à un répertoire du serveur pour lequel il n’a pas les permissions. Le serveur répond par 403 Forbidden.

4. 404 Not Found

Le serveur n’a trouvé aucune ressource correspondant à l’URI de la requête.

Exemple :

• Un utilisateur clique sur un lien brisé ou tape une URL qui n’existe pas sur le serveur. Le serveur renvoie 404 Not Found.

5. 405 Method Not Allowed

La méthode de requête est connue par le serveur, mais a été désactivée et ne peut être utilisée.

Exemple :

• Un client tente de soumettre des données à un serveur en utilisant la méthode GET alors que le serveur exige que ces données soient soumises via POST. Le serveur répond 405 Method Not Allowed.

6. 406 Not Acceptable

Le serveur ne trouve pas de contenu répondant aux critères donnés par l’agent utilisateur, par exemple, dans les en-têtes de négociation de contenu.

Exemple :

• Un client demande une version de page uniquement en français, mais le serveur ne dispose que de versions en anglais. Le serveur répond 406 Not Acceptable.

7. 407 Proxy Authentication Required

Semblable au code 401, mais il indique que l’authentification doit être faite par un proxy.

Exemple :

• Un client doit s’authentifier avec un proxy pour obtenir l’autorisation de voir un certain contenu. Le proxy répond par 407 Proxy Authentication Required.

8. 408 Request Timeout

Le serveur veut fermer la connexion inutilisée. Il est envoyé sur une connexion inactive où le serveur attendait que la requête soit envoyée par le client.

Exemple :

• Un client établit une connexion avec un serveur, mais prend trop de temps à envoyer la requête. Le serveur répond par 408 Request Timeout.

9. 409 Conflict

Ce code est renvoyé lorsque la requête entre en conflit avec l’état actuel du serveur.

Exemple :

• Un utilisateur essaie de modifier une information qui est déjà mise à jour par un autre utilisateur. Le serveur répond 409 Conflict.

10. 410 Gone

Similaire à 404, mais il indique que la ressource n’est plus disponible et ne le sera plus.

Exemple :

• Un utilisateur demande une page qui était autrefois active, mais a été définitivement supprimée. Le serveur renvoie 410 Gone.

11. 411 Length Required

Ce code est envoyé lorsque le serveur nécessite que la longueur du contenu de la requête soit définie et que le client n’a pas spécifié cette longueur.

Exemple :

• Un client envoie une requête POST sans l’en-tête Content-Length. Le serveur, nécessitant cette information pour traiter la requête, répond avec 411 Length Required.

12. 412 Precondition Failed

Le serveur ne peut pas répondre à la requête, car une ou plusieurs conditions spécifiées dans les en-têtes de la requête (comme If-Match) ne sont pas remplies.

Exemple :

• Un client tente de télécharger une version spécifique d’un fichier uniquement si elle n’a pas été modifiée. Si le fichier a été changé, le serveur répond par 412 Precondition Failed.

13. 413 Payload Too Large

La requête est plus volumineuse que les limites que le serveur est prêt ou capable de traiter.

Exemple :

• Un client tente de télécharger une image de grande taille sur un serveur configuré pour n’accepter que des tailles de fichier maximales de 5MB. Le serveur répond avec 413 Payload Too Large.

14. 414 URI Too Long

L’URI demandée par le client est plus longue que le serveur est disposé à interpréter.

Exemple :

• Un client envoie une URL extrêmement longue à la suite d’une mauvaise configuration d’un formulaire ou d’une attaque de type « buffer overflow« . Le serveur renvoie 414 URI Too Long.

15. 415 Unsupported Media Type

Le type de média des données de la requête n’est pas pris en charge par le serveur.

Exemple :

• Un client tente de télécharger un fichier avec une extension .xyz que le serveur ne reconnaît pas. Le serveur renvoie 415 Unsupported Media Type.

16. 416 Range Not Satisfiable

Le client a demandé une portion de fichier, mais le serveur ne peut pas fournir cette partie.

Exemple :

• Un client demande une partie d’un fichier vidéo qui est hors des limites du fichier. Le serveur répond avec 416 Range Not Satisfiable.

17. 417 Expectation Failed

Le serveur ne peut pas répondre aux exigences de l’en-tête Expect de la requête.

Exemple :

• Un client envoie une requête avec l’en-tête Expect: 100-continue, mais le serveur ne gère pas cette attente. Le serveur répond avec 417 Expectation Failed.

18. 418 I’m a teapot

Ce code est une blague du 1er avril, issu de la RFC 2324, signalant que la machine est une théière et non une cafetière.

Exemple :

• Souvent utilisé à titre humoristique, ce code peut être renvoyé par des serveurs configurés pour répondre de manière non conventionnelle à certaines requêtes.

19. 422 Unprocessable Entity

Le serveur comprend le type de contenu de la requête et la syntaxe de la requête est correcte, mais il n’a pas pu traiter les instructions contenues.

Exemple :

• Un client envoie des données JSON mal formées que le serveur comprend, mais ne peut pas traiter, aboutissant à 422 Unprocessable Entity.

20. 425 Too Early

Indique que le serveur refuse de risquer de traiter une requête qui pourrait être rejouée, pouvant provoquer des dommages dans des environnements avec des requêtes précoces.

Exemple :

• Utilisé principalement dans des contextes de sécurité où la chronologie des requêtes est cruciale, et le serveur renvoie 425 Too Early pour éviter les actions potentiellement dangereuses.

21. 426 Upgrade Required

Le client devrait changer de protocole, par exemple, en passant de HTTP/1.1 à HTTP/2.

Exemple :

• Lorsqu’un client se connecte à un serveur qui requiert HTTP/2, le serveur peut renvoyer 426 Upgrade Required avec des instructions sur la mise à niveau nécessaire.

22. 428 Precondition Required

Le serveur requiert que la requête du client soit conditionnelle pour s’assurer de sa fraîcheur ou de sa validité.

Exemple :

• Utilisé pour prévenir les problèmes tels que les mises à jour perdues lors d’une requête PUT, le serveur peut répondre avec 428 Precondition Required si les en-têtes de condition ne sont pas présents.

23. 429 Too Many Requests

Le client a envoyé trop de requêtes dans un laps de temps donné.

Exemple :

• Un site peut limiter le nombre de requêtes qu’un utilisateur peut faire à une API pour prévenir le spam ou l’abus. Si ce seuil est dépassé, le serveur renvoie 429 Too Many Requests.

24. 431 Request Header Fields Too Large

Le serveur est incapable de traiter la requête parce que les champs d’en-tête sont trop grands.

Exemple :

• Si un client envoie une requête avec des en-têtes extrêmement volumineux, le serveur peut répondre avec 431 Request Header Fields Too Large.

25. 451 Unavailable For Legal Reasons

Ce code est utilisé lorsque le contenu a été retiré pour des raisons juridiques, comme la censure ou les restrictions géographiques.

Exemple :

• Si un contenu est inaccessible dans certains pays en raison de restrictions légales, le serveur peut utiliser 451 Unavailable For Legal Reasons pour informer les utilisateurs de la restriction.

26. 499 Client Closed Request

Utilisé par NGINX pour signaler que le client a fermé la connexion avant que le serveur ait terminé de traiter sa requête.

Exemple :

• Lorsqu’un utilisateur ferme son navigateur ou interrompt la connexion alors que le serveur est toujours en train de traiter la requête, NGINX peut enregistrer l’erreur 499 Client Closed Request.

Conclusion

Les codes de statut HTTP 400 mettent en lumière les diverses erreurs qui peuvent survenir du côté client lors de la navigation web. Ils offrent aux développeurs des informations précieuses pour diagnostiquer et résoudre les problèmes, contribuant ainsi à une interaction plus fluide entre les utilisateurs et les serveurs. Maîtriser ces codes et comprendre les conditions sous lesquelles ils sont émis permet aux développeurs de créer des sites web plus fiables et conviviaux. En somme, une connaissance approfondie des codes de statut 400 est essentielle pour toute personne impliquée dans le développement et la maintenance de sites web.

Précédent

Codes de statut HTTP 300 : découvrir la signification des codes de la série 300

Suivant

Codes de statut HTTP 500 : découvrir la liste de codes d'état 500 et leurs explications

Jac

Passionné par la découverte de nouvelles technologies, Jac explore régulièrement les dernières tendances en high tech et finance, offrant à ses lecteurs des critiques éclairées et des conseils pratiques sur WordPress et les outils innovants.Son engagement à demeurer au cœur de l'actualité technologique fait de lui une voix fiable et respectée sur notre site.