Assiste.com - Sécurité informatique - Vie privée sur le Web - Neutralité d'Internet Assiste.com - Sécurité informatique - Vie privée sur le Web - Neutralité d'Internet

Code d'état HTTP 200 (OK)

Code HTTP 200 (OK) (OK)

cr  07.04.2018      r+  18.03.2022      r-  19.04.2024      Pierre Pinard.         (Alertes et avis de sécurité au jour le jour)

Dans les relations « client / serveur » utilisant le protocole HTTP (et HTTPS), les codes HTTP (‘HTTP Status code’ – « Code d'état HTTP ») sont des codes à 3 ou 4 chiffres que renvoie le serveur au client (un navigateur Web ou un robot tels les robots parcourant le Web pour l'indexer ou un logiciel aspirateur de sites Web, etc.) qui lui a envoyé une requête HTTP pour lui dire s'il a bien reçu la requête, s'il a été capable de l'interpréter, quelle suite il donne, quelle erreur il a rencontrée, etc.

Ces codes sont destinés aux traitements automatiques par les « clients HTTP ». Ils ont été normalisés et sont spécifiés dans la RFC ("Request for Comments" - « Demande de commentaires ») [1] [2] [3] 2016. D’autres codes HTTP (‘HTTP Status code’ – « Code d'état HTTP »), initialement non normalisés, mais très utilisés sur le Web, ont ensuite été ajoutés par la RFC [4] 7231.

Il existe également des codes HTTP spécifiés et largement utilisés bien que hors de toute RFC.

Les codes HTTP sont des codes d'état. Certains indiquent un état d'erreur. Ce sont alors des codes erreur : ils indiquent un état d'erreur. Il est alors utilisé des expressions pas très justes comme :

  • Erreur 200
  • Code erreur 200


Code HTTP

200

Message (en anglais)

OK

Message (en français)

OK

Type de code

Code de succès (Codes 2nn - Codes commençant par 2).
La requête a abouti. L'information retournée en réponse dépend de la requête émise, comme suit :

  • GET : Une entité correspondant à l'URI visée par la requête est renvoyée au client

  • HEAD : La réponse au client ne doit contenir que les champs d'en-tête à l'exclusion de tout corps d'entité

  • POST : Une entité décrivant le résultat de l'action entreprise.

Signification

Requête traitée avec succès. La requête HTTP a été traitée avec succès. L'information retournée avec la réponse dépend de la méthode utilisée dans la requête. Par exemple la réponse à une requête GET classiquement émise par un navigateur Web sera la ressource demandée (c'est-à-dire une page HTML, une image, etc.).

Page du code dans la RFC anglaise 2616
https://tools.ietf.org/html/rfc2616#page-58
Page du code dans la RFC anglaise 7231
https://tools.ietf.org/html/rfc7231#page-51
Page du code dans la RFC française 2661
http://abcdrfc.free.fr/rfc-vf/pdf/rfc2616.pdf
Autres ressources

5.1 Fondements : vue d’ensemble de la validation d’antémémoire HTTP

Lorsque un client a une réponse dans son antémémoire, et souhaite s’assurer que cette entrée d’antémémoire est valide, HTTP/1.1 permet au client de faire un "GET conditionnel", en utilisant une des deux formes de "valideurs d’antémémoire". Dans la forme traditionnelle, disponible aussi bien dans HTTP/1.0 que dans HTTP/1.1, le client peut utiliser l’en-tête de demande "Si-Modifié-depuis" pour présenter au serveur l’horodatage "Dernière-modification" (s’il y en a un) que le serveur a fourni avec la réponse. Si l’horodatage du serveur pour la ressource n’a pas changé, il peut envoyer une réponse avec un code d’état de 304 (Non modifié) qui ne transmet pas le corps de la ressource. Si l’horodatage a changé, le serveur va normalement envoyer une réponse avec un code d’état de 200 (OK) qui porte une copie complète de la ressource, et un nouvel horodatage Dernière-modification.

Cette approche fondée sur l’horodatage est sujette à erreur à cause du manque de résolution de l’horodatage : si une ressource change deux fois en une seconde, le changement peut n’être pas détectable. Donc, HTTP/1.1 permet aussi au serveur de fournir une étiquette entité avec une réponse. Une étiquette entité est une chaîne opaque, construite par le serveur selon ses propres besoins ; la spécification du protocole impose un minimum simple d’exigences aux étiquettes d’entité. (En particulier, une étiquette d’entité "forte" doit changer si la valeur de la ressource change.) Dans ce cas, le client peut valider son entrée d’antémémoire en envoyant sa demande conditionnelle en utilisant l’en-tête de demande "Si-aucune-correspondance", présentant l’étiquette d’entité associée à la réponse en antémémoire. (Le protocole définit plusieurs autres façons de transmettre les étiquettes d’entité, comme l’en-tête "Si-Gamme", utilisé pour court-circuiter un aller-retour qui serait autrement nécessaire.) Si l’étiquette d’entité présentée correspond à l’étiquette actuelle du serveur pour la ressource, le serveur devrait envoyer une réponse 304 (Non modifié). Autrement, le serveur devrait envoyer une réponse 200 (OK) avec une copie complète de la ressource.

Dans le protocole HTTP existant (HTTP/1.0 ou HTTP/1.1) un client qui envoie une demande conditionnelle peut s’attendre à l’une de ces deux réponses :

  1. état = 200 (OK), avec une copie complète de la ressource, parce que la copie de la ressource du serveur est vraisemblablement différente de la copie en antémémoire du client.
  2. état = 304 (Non modifié), sans corps, parce que la copie de la ressource du serveur est vraisemblablement la même que la copie en antémémoire du client.

De façon informelle, on peut voir cela comme des "deltas" respectivement de 100 % et de 0 % de la ressource. Noter que ces deltas sont relatifs à une réponse en antémémoire spécifique. C’est-à-dire qu’un client ne peut pas demander un delta sans spécifier, d’une certaine manière, quelles sont les deux instances d’une ressource qui sont à différencier. La "nouvelle" instance est implicitement l’instance en cours que le serveur va retourner pour une demande inconditionnelle, et la "vieille" instance est celle qui est actuellement dans l’antémémoire du client. Le valideur d’antémémoire (heure de dernière modification ou étiquette entité) est ce qui est utilisé pour communiquer au serveur l’identité de la vieille instance.








  1. Microsoft (FR) : Codes d’état HTTP dans Microsoft Internet Information Services (IIS) 7.0 et versions ultérieures.

  2. Microsoft (FR) : Codes status HTTP (Recherche Azure AI)

  3. Microsoft (FR) : Codes d’état HTTP (Winhttp.h)

  4. Microsoft (FR) : Codes d’état HTTP (Wininet.h)

  5. Microsoft (FR) : Obtenir et analyser les codes de réponse HTTP

  6. Microsoft (FR) : Gestion de code d’état avec Web.Contents

  7. Microsoft (FR) : Codes d’état HTTP pour Azure Cosmos DB

  8. Microsoft (FR) : Utilisation des erreurs détaillées HTTP dans IIS 7.0

  9. Microsoft (FR) : HttpStatusCode Énumération

  10. Microsoft (FR) : Codes de réponse HTTP dans Application Gateway

  11. Microsoft (FR) : Codes d’erreur REST de l’Espace partenaires

  12. Microsoft (FR) : Codes status répétés « 401 » et « 200 » lors de l’utilisation de MAPI sur HTTP

  13. Microsoft (FR) : État du lot et codes d’erreur (Codes d'erreur d'API REST courants ; Codes d'erreur du service de traitement par lots ; Codes d'erreur de planification de travail/tâche)

  14. Microsoft (FR) : Prise en charge de HTTP dans .NET

  15. Microsoft (FR) : Codes d’état et d’erreur (Réponses d’erreur pour le stockage table)

  16. Microsoft (FR) : Codes d’erreur de l’API du service de requête