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

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.