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 304 (Not Modified)

Code HTTP 304 (Not Modified) (Non modifié)

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 304
  • Code erreur 304


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)
Cette classe de messages précise que le client doit provoquer une action complémentaire pour que la requête puisse être conduite jusqu'à sa résolution finale. L'action peut être déclenchée par l'utilisateur final si et seulement si la méthode invoquée était GET ou HEAD. Un client ne peut automatiquement rediriger une requête plus de 5 fois. Il est supposé, si cela arrive, que la re-direction s'effectue selon une boucle infinie.

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 :

  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