Pour un document public modifiable, choisissez la revalidation si vous voulez que les lecteurs obtiennent le contenu à jour tout en permettant de réutiliser les pages inchangées. Choisissez no-store si vos exigences de publication excluent spécifiquement le stockage dans le cache HTTP.

Ce guide s’adresse à une personne qui gère un document public depuis un ordinateur de bureau Mac. Il s’agit de choisir une politique de réponse, puis de la vérifier dans Terminal à l’aide d’une page synthétique contenant uniquement du texte neutre, comme « Guide des formes, version un ». Il vous faut une page de test et l’accès à sa configuration d’hébergement, ou un fournisseur capable de configurer ses en-têtes de réponse.

Quelle politique de mise en cache convient au document ?

Commencez par définir l’exigence de publication. La page doit-elle être vérifiée avant chaque réutilisation, une copie existante peut-elle rester utilisable pendant une courte période, ou les caches HTTP doivent-ils éviter de stocker la réponse ? Il s’agit d’exigences différentes selon RFC 9111 : mise en cache HTTP.

Exigence de publication En-tête de réponse possible Signification pour un cache HTTP
Vérifier avant chaque réutilisation Cache-Control: no-cache Le stockage est autorisé ; la réutilisation nécessite une validation réussie.
Autoriser une courte période de fraîcheur Cache-Control: max-age=300, must-revalidate La réutilisation est autorisée tant que la réponse est fraîche ; une fois périmée, une validation réussie est requise.
Exclure le stockage de la réponse Cache-Control: no-store Le cache ne doit pas stocker la réponse ni l’utiliser pour une autre requête.

La période de cinq minutes est un exemple, pas une valeur par défaut recommandée. Ne la choisissez que si votre document peut tolérer cet intervalle de réutilisation. must-revalidate seul n’impose pas de vérification tant que la réponse est fraîche. Ces distinctions découlent des directives de réponse de la RFC 9111.

Pour le guide des formes synthétique, supposons qu’une correction de « trois exemples » à « quatre exemples » doive être vérifiée lors de la prochaine récupération. Commencez par no-cache et un validateur fonctionnel. Si votre exigence stipule plutôt que les caches HTTP ne doivent pas conserver cette réponse de document, choisissez no-store. Le fait qu’un document soit fréquemment modifié ne suffit pas à établir que son stockage doit être exclu.

Formulez l’exigence avant de modifier les paramètres : « Vérifier le document avant sa réutilisation », par exemple. Vous disposez ainsi d’un critère d’acceptation concret et évitez de laisser le nom d’un paramètre décider de la politique.

Qu’est-ce qui permet à la revalidation de fonctionner ?

Un validateur identifie la version déjà reçue par le client. Un ETag fournit une étiquette d’entité ; Last-Modified fournit un horodatage de modification. La RFC 9110 recommande d’envoyer les validateurs disponibles pour les récupérations réussies de documents, en privilégiant une étiquette d’entité forte et une date de modification. Consultez Sémantique HTTP, validateurs et 200 OK.

Il s’agit d’exemples de champs d’en-tête de réponse, et non de code de configuration du serveur. Ils supposent que le corps de la réponse est le guide des formes synthétique :

Cache-Control: no-cache
ETag: "shape-guide-v1"

Lors d’une requête ultérieure, un client peut envoyer If-None-Match: "shape-guide-v1". Si cette étiquette correspond toujours à la représentation sélectionnée, la GET conditionnelle reçoit 304 Not Modified, sans corps de réponse. Si elle ne correspond plus, le traitement normal peut renvoyer le document modifié. Les règles figurent dans la section de la RFC 9110 consacrée aux requêtes conditionnelles.

L’exigence de mise en œuvre est que le validateur suive la version du document. Ne copiez pas l’étiquette illustrative dans une configuration permanente en la laissant inchangée après les modifications. Demandez à votre système d’hébergement de générer des validateurs de façon cohérente et de traiter les conditions entrantes.

Dans quelle mesure une réponse inchangée peut-elle éviter un transfert ?

Prenons un calcul donné à titre d’illustration : le corps d’un document fait 80 000 octets, et un client le récupère 100 fois sans aucune modification. Une réponse complète, suivie de 99 validations réussies, transfère 80 000 octets de corps au lieu de 8 000 000, soit une différence de 7 920 000 octets.

Ce calcul exclut les en-têtes, la compression, la surcharge de connexion et tout traitement applicatif. Il porte uniquement sur le transfert du corps. L’explication de la mise en cache HTTP de Google décrit le même échange : un validateur correspondant permet un 304 sans corps, et le client utilise le contenu qu’il a reçu précédemment. Les économies réelles dépendent de la fréquence de modification des documents et de la manière dont les clients effectuent leurs requêtes.

Où configurer la politique ?

Configurez la réponse HTTP générée par votre service d’hébergement, votre serveur ou votre couche de diffusion de contenu. Les exemples d’en-têtes ci-dessus décrivent le résultat attendu ; ce ne sont pas des commandes universelles pour une plateforme de publication.

Si votre éditeur ne vous permet de modifier que le texte du document, une solution de contournement dans le balisage ne vous donne pas un contrôle équivalent. La norme HTML WHATWG ne définit pas Cache-Control comme une directive http-equiv prise en charge et explique que ces directives sont en grande partie distinctes des en-têtes HTTP. Consultez Norme HTML : directives pragma.

La méthode prise en charge consiste à utiliser la configuration des en-têtes de réponse documentée par votre hébergeur ou à demander au fournisseur de la mettre en œuvre. La présentation des robots d’exploration de Google oriente également les éditeurs vers leur fournisseur d’hébergement ou de gestion de contenu pour la mise en œuvre de la mise en cache HTTP. Une demande utile précise le document, la politique choisie et le comportement du validateur, puis demande comment vérifier la réponse envoyée.

La modification d’une option de requête JavaScript a une portée plus limitée. WHATWG définit un mode cache no-store de Fetch qui se comporte comme s’il n’y avait pas de cache HTTP, tandis que no-cache effectue une requête conditionnelle lorsqu’une réponse en cache appropriée existe. Ces modes régissent cette requête ; en définir un dans un script ne configure pas la politique de réponse du serveur pour le document. Consultez les modes de cache de la norme Fetch.

Comment tester la revalidation depuis un Mac ?

Utilisez un document de test public synthétique que vous pouvez modifier. Avant de commencer, donnez-lui le contenu « Guide des formes, version un » et faites en sorte que les en-têtes de réponse choisis soient envoyés. Gardez ce test séparé du contenu réel de vos documents afin de pouvoir effectuer une modification manifeste et réversible.

Ouvrez Terminal et exécutez les commandes suivantes dans la même session. Elles vous demandent l’URL réelle de votre page de test et le validateur renvoyé par cette page ; aucune adresse d’exemple n’est supposée. Arrêtez-vous après la première requête si elle échoue, est redirigée ou renvoie autre chose que la réponse prévue pour le document.

printf '%s\n' 'Paste the full URL of your synthetic public test page:'
IFS= read -r page_url

curl --silent --show-error --connect-timeout 5 --max-time 20 \
  --dump-header - --output /dev/null --url "$page_url"

printf '%s\n' 'Paste its ETag value exactly, including quotes:'
IFS= read -r page_etag

check_page() {
  curl --silent --show-error --connect-timeout 5 --max-time 20 \
    --dump-header - --output /dev/null \
    --header "If-None-Match: $page_etag" --url "$page_url"
}

check_page

Les commandes effectuent des requêtes GET, affichent les en-têtes reçus et écartent délibérément le corps de la réponse. Les délais d’attente limitent la durée de connexion et de transfert ; les erreurs restent visibles. Ces options sont documentées dans le manuel de curl. La première requête doit révéler la valeur Cache-Control choisie et un ETag. Si aucune étiquette n’est présente, n’entrez pas une valeur inventée : commencez par résoudre la prise en charge des validateurs.

Copiez la valeur complète de l’étiquette, guillemets compris, ainsi que tout préfixe W/. Si la représentation correspondante est inchangée, la requête conditionnelle devrait renvoyer 304. Une 304 ne peut pas contenir de contenu et doit inclure les métadonnées indiquées qui accompagneraient la réponse 200 équivalente, notamment ETag et Cache-Control le cas échéant. Consultez RFC 9110 : 304 Not Modified.

Tester une modification en conservant l’ancien validateur

Modifiez le document synthétique pour qu’il contienne « Guide des formes, version deux : quatre exemples. » Une fois la mise à jour visible sur votre page de test, conservez l’ancienne étiquette dans la même session Terminal et exécutez cette commande de suivi :

check_page

Pour ce document volontairement modifié, attendez-vous à ce que le nouveau corps soit disponible dans une réponse normale réussie et que le validateur soit mis à jour. Ensuite, répétez les commandes initiales avec la nouvelle étiquette et vérifiez à nouveau la version inchangée. Cela teste les deux cas : reconnaître une modification et reconnaître l’absence de modification.

Observation Étape de diagnostic suivante
La requête initiale renvoie une redirection Utilisez l’URL finale du document et recommencez le test.
La requête conditionnelle sans modification renvoie 200 Vérifiez que vous avez correctement copié l’étiquette et que le traitement conditionnel est activé.
Une modification volontaire du contenu produit toujours 304 avec l’ancienne étiquette Examinez la propagation de la mise à jour et la génération du validateur avant de vous fier à la revalidation.
La politique envoyée diffère de votre configuration Examinez les paramètres d’hébergement et de diffusion responsables de la réponse finale.
La requête expire ou échoue Résolvez l’échec de récupération avant d’interpréter le comportement du cache.

Il s’agit de pistes de diagnostic, et non de preuves d’une cause particulière. La procédure teste la réponse et l’échange conditionnel ; elle ne permet pas d’établir le comportement de tous les navigateurs. Pour évaluer no-store, examinez directement cette directive de réponse. Une requête conditionnelle que vous construisez manuellement ne permet pas de vérifier si un navigateur a stocké une réponse.

Qu’est-ce que cela signifie pour Google Search ?

La documentation actuelle de Google sur ses robots d’exploration prend en charge ETag avec If-None-Match et Last-Modified avec If-Modified-Since. Elle recommande ETag pour les robots d’exploration de Google et indique que chaque robot peut gérer la mise en cache différemment. Consultez Présentation des robots d’exploration et des récupérateurs de Google.

Cette page indique également que les autres directives de mise en cache HTTP ne sont pas prises en charge, tout en suggérant séparément max-age comme indice possible de nouvelle exploration, avec Last-Modified. Compte tenu de cette limite documentée, ne supposez pas que votre politique no-store ou no-cache destinée aux navigateurs détermine le calendrier de récupération de Googlebot. Mettez en œuvre et testez les validateurs comme méthode documentée de récupération conditionnelle.

Google explique qu’un 304 signale à ses systèmes de traitement que le contenu n’a pas changé ; pour la recherche, cela n’a sinon aucun effet sur l’indexation. Une 200 réussie ne garantit pas non plus l’indexation. Ces éléments sont documentés dans Comment les codes d’état HTTP affectent les robots d’exploration de Google.

Choisissez la politique qui correspond aux exigences de votre document, puis conservez les éléments de vérification : la réponse initiale, une réponse conditionnelle sans modification et une réponse après une modification volontaire. Pour un document public qui doit être vérifié avant sa réutilisation, la revalidation constitue un point de départ pratique. Choisissez no-store si l’exclusion du stockage dans le cache HTTP est en elle-même une exigence.

Sources