Flux RSS - La vie du site - Nouveautés et mises à jour
Assiste.com - Sécurité informatique - Décontamination - Antivirus - Protection - Protection de la Vie Privée Assiste.com - Sécurité informatique préventive - Décontamination - Antivirus - Protection - Protection de la Vie Privée

Code HTTP 200 (OK) (OK)

 - Code HTTP 200 Code HTTP 200Ecrire à Assiste.com -  - Code HTTP 200  -

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 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 ») 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 7231.

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


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.

200 - Code HTTP 200

200 - Ressources Ressources200 - Ressources 200