Code d'état HTTP 304

304 Non modifié

Si le client envoie une requête GET conditionnelle et que la requête est autorisée, mais que le contenu du document n'a pas changé (depuis le dernier accès ou selon les conditions de la requête), le serveur doit renvoyer ce statut code. Il est interdit à une réponse 304 d'inclure un corps de message, elle se termine donc toujours par la première ligne vide après l'en-tête du message.

La réponse doit contenir les informations d'en-tête suivantes :

Date, sauf si le serveur ne dispose pas d'horloge. Si les serveurs sans horloge suivent ces règles, alors les serveurs proxy et les clients peuvent ajouter eux-mêmes le champ Date aux en-têtes de réponse reçus (comme spécifié dans la RFC 2068), et le mécanisme de mise en cache fonctionnera normalement.

ETag et/ou Content-Location, si la même requête aurait dû renvoyer une réponse de 200.

Expires, Cache-Control et/ou Vary, si sa valeur peut être différente de la valeur correspondant à d'autres réponses précédentes de la même variable.

Si cette demande de réponse utilise une vérification de cache forte, alors cette réponse ne doit pas contenir d'autres en-têtes d'entité ; sinon (par exemple, une requête GET conditionnelle utilise une vérification de cache faible), il est interdit à cette réponse de contenir d'autres en-têtes d'entité ; contenu de l'entité mis en cache et informations d'en-tête d'entité mises à jour.

Si une réponse 304 indique qu'une entité n'est actuellement pas mise en cache, le système de mise en cache doit ignorer la réponse et répéter la demande sans restriction.

Si une réponse 304 est reçue nécessitant une mise à jour d'une entrée de cache, le système de cache doit mettre à jour l'intégralité de l'entrée pour refléter les valeurs de tous les champs qui ont été mis à jour dans la réponse.