Assiste.com
cr 07.04.2018 r+ 18.03.2022 r- 19.04.2024 Pierre Pinard. (Alertes et avis de sécurité au jour le jour)
Dossier (collection) : Codes d'état HTTP - RFC 2616 |
---|
Introduction Liste Malwarebytes et Kaspersky ou Emsisoft (incluant Bitdefender) |
Sommaire (montrer / masquer) |
---|
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 :
Code HTTP | 304 |
Message (en anglais) | Not Modified |
Message (en français) | Non modifié |
Type de code | Code de redirection (Codes 3nn - Codes commençant par 3) |
Signification | Document non modifié depuis la dernière requête. Le navigateur Web a effectué une requête GET conditionnelle et l'accès est autorisé, mais le document n'a pas été modifié. Cette réponse classique signifie que vous avez configuré votre navigateur pour utiliser un cache HTTP (proxy) dans lequel une copie du document demandé est déjà stockée. Le proxy a donc demandé au serveur si le document original a changé depuis, et a reçu cette réponse : il pourra ainsi utiliser la copie locale. En informatique, un " Cache " est un dispositif accélérateur relevant du principe d'anticipation. Plusieurs termes sont des synonymes : "mémoire cache", "antémémoire", "mémoire prédictive", "mémoire d'anticipation". Un " cache " est une zone de mémoire intermédiaire, servant à l'accélération d'une fonction, en tenant à la disposition de certains processus, des données prêtes à l'emploi, sans avoir à aller les chercher. Lire : Cache |
Page du code dans la RFC anglaise 2616 | https://tools.ietf.org/html/rfc2616#page-63 |
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 :
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.
Aidez Assiste – autorisez quelques publicités et cliquez-les |
↑ Hypertext Transfer Protocol -- HTTP/1.1 - Status Code Definitions (w3.org - RFC 2616 - juin 1999) [Archive]
↑ Hypertext Transfer Protocol -- HTTP/1.1 - Status Code Definitions (ietf.org - RFC 2616 - juin 1999) [Archive]
↑ Protocole de transfert Hypertexte -- HTTP/1.1 (abcdrfc.free.fr - RFC 2616 - juin 1999) [Archive]
↑ HTTP/1.1 Semantics and Content, page 49) (ietf.org - RFC 7231 - juin 2014) [Archive]
Microsoft (FR) : Obtenir et analyser les codes de réponse HTTP
Microsoft (FR) : Utilisation des erreurs détaillées HTTP dans IIS 7.0
Microsoft (FR) : Codes de réponse HTTP dans Application Gateway
Microsoft (FR) : Codes d’erreur REST de l’Espace partenaires
Microsoft (FR) : Codes status répétés « 401 » et « 200 » lors de l’utilisation de MAPI sur HTTP
Microsoft (FR) : Codes d’état et d’erreur (Réponses d’erreur pour le stockage table)
Microsoft (FR) : Codes d’erreur de l’API du service de requête