Aller au contenu principal

4. Construction des réponses à partir des caches

Lorsqu'une requête lui est présentée, un cache MUST NOT réutiliser une réponse stockée, sauf si :

  • l'URI de requête effective présentée (Section 5.5 du [RFC7230]) et celle de la réponse stockée correspondent, et

  • la méthode de requête associée à la réponse stockée permet de l'utiliser pour la requête présentée, et

  • les champs d'en-tête de sélection désignés par la réponse stockée (le cas échéant) correspondent à ceux présentés (voir Section 4.1), et

  • la requête présentée ne contient ni le pragma no-cache (Section 5.4), ni la directive de cache no-cache (Section 5.2.1), sauf si la réponse stockée est validée avec succès (Section 4.3), et

  • la réponse stockée ne contient pas la directive de cache no-cache (Section 5.2.2.2), sauf si elle est validée avec succès (Section 4.3), et

  • la réponse stockée est soit :

    • fraîche (voir Section 4.2), soit

    • autorisée à être servie périmée (voir Section 4.2.4), soit

    • validée avec succès (voir Section 4.3).

Notez que l'une quelconque des exigences énumérées ci-dessus peut être supplantée par une extension de contrôle de cache ; voir la Section 5.2.3.

Lorsqu'une réponse stockée est utilisée pour satisfaire une requête sans validation, un cache MUST générer un champ d'en-tête Age (Section 5.1), en remplaçant celui éventuellement présent dans la réponse par une valeur égale au current_age de la réponse stockée ; voir la Section 4.2.3.

Un cache MUST transmettre sans modification (« write through ») vers le serveur d'origine les requêtes dont la méthode est non sûre (Section 4.2.1 du [RFC7231]) ; autrement dit, un cache n'est pas autorisé à générer une réponse à une telle requête avant d'avoir transmis la requête et reçu une réponse correspondante.

Notez également que les requêtes non sûres peuvent invalider des réponses déjà stockées ; voir la Section 4.4.

Lorsque plusieurs réponses appropriées sont stockées, un cache MUST utiliser la réponse la plus récente (telle que déterminée par le champ d'en-tête Date). Il peut également transmettre la requête avec « Cache-Control: max-age=0 » ou « Cache-Control: no-cache » pour lever l'ambiguïté sur la réponse à utiliser.

Un cache qui ne dispose pas d'horloge MUST NOT utiliser de réponses stockées sans les revalider à chaque utilisation.

4.1. Calcul des clés secondaires avec Vary​

Lorsqu'un cache reçoit une requête qui peut être satisfaite par une réponse stockée comportant un champ d'en-tête Vary (Section 7.1.4 du [RFC7231]), il MUST NOT utiliser cette réponse, sauf si tous les champs d'en-tête de sélection désignés par le champ d'en-tête Vary correspondent à la fois dans la requête d'origine (c'est-à-dire celle associée à la réponse stockée) et dans la requête présentée.

Les champs d'en-tête de sélection de deux requêtes sont définis comme correspondant si et seulement si ceux de la première requête peuvent être transformés en ceux de la seconde en appliquant l'une des opérations suivantes :

  • ajouter ou supprimer des espaces, là où la syntaxe du champ d'en-tête le permet,

  • combiner plusieurs champs d'en-tête portant le même nom de champ (voir Section 3.2 du [RFC7230]),

  • normaliser les deux valeurs de champ d'une manière connue pour avoir une sémantique identique, conformément à la spécification du champ d'en-tête (par exemple, réordonner les valeurs de champ lorsque l'ordre n'est pas significatif ; normaliser la casse, lorsque les valeurs sont définies comme insensibles à la casse).

Si (après toute normalisation éventuelle) un champ d'en-tête est absent d'une requête, il ne peut correspondre à une autre requête que s'il y est également absent.

Une valeur de champ d'en-tête Vary égale à « * » échoue toujours à correspondre.

La réponse stockée dont les champs d'en-tête de sélection correspondent est appelée réponse sélectionnée.

Si plusieurs réponses sélectionnées sont disponibles (y compris éventuellement des réponses sans champ d'en-tête Vary), le cache devra en choisir une à utiliser. Lorsqu'un champ d'en-tête de sélection dispose d'un mécanisme connu pour ce faire (par exemple les qvalues sur Accept et les champs d'en-tête de requête similaires), ce mécanisme MAY être utilisé pour sélectionner les réponses préférées ; parmi le reste, la réponse la plus récente (telle que déterminée par le champ d'en-tête Date) est utilisée, conformément à la Section 4.

Si aucune réponse sélectionnée n'est disponible, le cache ne peut pas satisfaire la requête présentée. Typiquement, elle est transmise au serveur d'origine dans une requête (éventuellement conditionnelle ; voir Section 4.3).

4.2. Fraîcheur​

Une réponse fraîche est une réponse dont l'âge n'a pas encore dépassé sa durée de fraîcheur. À l'inverse, une réponse périmée est une réponse dont l'âge l'a dépassée.

La durée de fraîcheur d'une réponse est l'intervalle de temps entre sa génération par le serveur d'origine et son instant d'expiration. Un instant d'expiration explicite est l'instant auquel le serveur d'origine prévoit qu'une réponse stockée ne pourra plus être utilisée par un cache sans validation supplémentaire, tandis qu'un instant d'expiration heuristique est attribué par un cache lorsqu'aucun instant d'expiration explicite n'est disponible.

L'âge d'une réponse est le temps écoulé depuis qu'elle a été générée par le serveur d'origine ou validée avec succès auprès de lui.

Lorsqu'une réponse est « fraîche » dans le cache, elle peut être utilisée pour satisfaire des requêtes ultérieures sans contacter le serveur d'origine, ce qui améliore l'efficacité.

Le mécanisme principal pour déterminer la fraîcheur consiste, pour un serveur d'origine, à fournir un instant d'expiration explicite dans le futur, au moyen soit du champ d'en-tête Expires (Section 5.3), soit de la directive de réponse max-age (Section 5.2.2.8). Généralement, les serveurs d'origine attribuent aux réponses des instants d'expiration explicites futurs en partant du principe que la représentation ne changera probablement pas de manière sémantiquement significative avant que l'instant d'expiration ne soit atteint.

Si un serveur d'origine souhaite forcer un cache à valider chaque requête, il peut attribuer un instant d'expiration explicite dans le passé pour indiquer que la réponse est déjà périmée. Les caches conformes valideront normalement une réponse mise en cache périmée avant de la réutiliser pour des requêtes ultérieures (voir Section 4.2.4).

Comme les serveurs d'origine ne fournissent pas toujours d'instants d'expiration explicites, les caches sont également autorisés à utiliser une heuristique pour déterminer un instant d'expiration dans certaines circonstances (voir Section 4.2.2).

Le calcul permettant de déterminer si une réponse est fraîche est le suivant :

response_is_fresh = (freshness_lifetime > current_age)

freshness_lifetime est défini à la Section 4.2.1 ; current_age est défini à la Section 4.2.3.

Les clients peuvent envoyer les directives de cache max-age ou min-fresh dans une requête afin de restreindre ou d'assouplir les calculs de fraîcheur pour la réponse correspondante (Section 5.2.1).

Lors du calcul de la fraîcheur, afin d'éviter les problèmes courants d'analyse des dates :

  • Bien que tous les formats de date soient spécifiés comme sensibles à la casse, un destinataire de cache SHOULD faire correspondre les noms de jour, de semaine et de fuseau horaire sans tenir compte de la casse.

  • Si l'implémentation interne du temps d'un destinataire de cache a une résolution inférieure à la valeur d'une HTTP-date, le destinataire MUST représenter en interne une date Expires analysée comme l'instant le plus proche égal ou antérieur à la valeur reçue.

  • Un destinataire de cache MUST NOT laisser les fuseaux horaires locaux influencer le calcul ou la comparaison d'un âge ou d'un instant d'expiration.

  • Un destinataire de cache SHOULD considérer comme invalide, pour le calcul de l'expiration, une date dont l'abréviation de fuseau horaire n'est ni GMT ni UTC.

Notez que la fraîcheur ne s'applique qu'au fonctionnement du cache ; elle ne peut pas être utilisée pour forcer un agent utilisateur à rafraîchir son affichage ou à recharger une ressource. Voir la Section 6 pour une explication de la différence entre les caches et les mécanismes d'historique.

4.2.1. Calcul de la durée de fraîcheur​

Un cache peut calculer la durée de fraîcheur (notée freshness_lifetime) d'une réponse en utilisant la première correspondance parmi les suivantes :

  • Si le cache est partagé et que la directive de réponse s-maxage (Section 5.2.2.9) est présente, utiliser sa valeur, ou

  • Si la directive de réponse max-age (Section 5.2.2.8) est présente, utiliser sa valeur, ou

  • Si le champ d'en-tête de réponse Expires (Section 5.3) est présent, utiliser sa valeur moins la valeur du champ d'en-tête de réponse Date, ou

  • Sinon, aucun instant d'expiration explicite n'est présent dans la réponse. Une durée de fraîcheur heuristique peut être applicable ; voir Section 4.2.2.

Notez que ce calcul n'est pas vulnérable à la dérive d'horloge, puisque toutes les informations proviennent du serveur d'origine.

Lorsque plusieurs valeurs sont présentes pour une directive donnée (par exemple, deux champs d'en-tête Expires, plusieurs directives Cache-Control: max-age), la valeur de la directive est considérée comme invalide. Les caches sont encouragés à considérer comme périmées les réponses dont les informations de fraîcheur sont invalides.

4.2.2. Calcul de la fraîcheur heuristique​

Comme les serveurs d'origine ne fournissent pas toujours d'instants d'expiration explicites, un cache MAY attribuer un instant d'expiration heuristique lorsqu'aucun instant explicite n'est spécifié, en employant des algorithmes qui utilisent d'autres valeurs de champs d'en-tête (telles que l'instant Last-Modified) pour estimer un instant d'expiration plausible. Cette spécification ne fournit pas d'algorithmes spécifiques, mais impose des contraintes de cas défavorable sur leurs résultats.

Un cache MUST NOT utiliser d'heuristiques pour déterminer la fraîcheur lorsqu'un instant d'expiration explicite est présent dans la réponse stockée. En raison des exigences de la Section 3, cela signifie qu'en pratique les heuristiques ne peuvent être utilisées que sur les réponses sans fraîcheur explicite dont les codes d'état sont définis comme pouvant être mis en cache par défaut (voir Section 6.1 du [RFC7231]), et sur les réponses sans fraîcheur explicite qui ont été marquées comme explicitement pouvant être mises en cache (par exemple, au moyen d'une directive de réponse « public »).

Si la réponse comporte un champ d'en-tête Last-Modified (Section 2.2 du [RFC7232]), les caches sont encouragés à utiliser une valeur d'expiration heuristique qui n'excède pas une certaine fraction de l'intervalle écoulé depuis cet instant. Un réglage typique de cette fraction pourrait être 10 %.

Lorsqu'une heuristique est utilisée pour calculer la durée de fraîcheur, un cache SHOULD générer dans la réponse un champ d'en-tête Warning avec le warn-code 113 (voir Section 5.5.4) si son current_age dépasse 24 heures et qu'un tel avertissement n'est pas déjà présent.

Note : La Section 13.9 du [RFC2616] interdisait aux caches de calculer une fraîcheur heuristique pour les URI comportant des composants de requête (c'est-à-dire ceux contenant '?'). En pratique, cela n'a pas été largement implémenté. Par conséquent, il est encouragé aux serveurs d'origine d'envoyer des directives explicites (par exemple Cache-Control: no-cache) s'ils souhaitent empêcher la mise en cache.

4.2.3. Calcul de l'âge​

Le champ d'en-tête Age est utilisé pour transmettre un âge estimé du message de réponse lorsqu'il est obtenu auprès d'un cache. La valeur du champ Age est l'estimation, par le cache, du nombre de secondes écoulées depuis que la réponse a été générée ou validée par le serveur d'origine. En substance, la valeur Age est la somme du temps pendant lequel la réponse a résidé dans chacun des caches sur le chemin depuis le serveur d'origine, plus la durée pendant laquelle elle a été en transit sur les chemins réseau.

Les données suivantes sont utilisées pour le calcul de l'âge :

age_value

Le terme « age_value » désigne la valeur du champ d'en-tête Age (Section 5.1), sous une forme appropriée à une opération arithmétique ; ou 0 s'il n'est pas disponible.

date_value

Le terme « date_value » désigne la valeur du champ d'en-tête Date, sous une forme appropriée aux opérations arithmétiques. Voir la Section 7.1.1.2 du [RFC7231] pour la définition du champ d'en-tête Date et pour les exigences relatives aux réponses qui en sont dépourvues.

now

Le terme « now » désigne « la valeur courante de l'horloge de l'hôte qui effectue le calcul ». Un hôte devrait utiliser NTP ([RFC5905]) ou un protocole similaire pour synchroniser ses horloges sur le temps universel coordonné.

request_time

La valeur courante de l'horloge de l'hôte au moment où la requête ayant abouti à la réponse stockée a été faite.

response_time

La valeur courante de l'horloge de l'hôte au moment où la réponse a été reçue.

L'âge d'une réponse peut être calculé de deux manières entièrement indépendantes :

  1. le « apparent_age » : response_time moins date_value, si l'horloge locale est raisonnablement bien synchronisée sur celle du serveur d'origine. Si le résultat est négatif, il est remplacé par zéro.

  2. le « corrected_age_value », si tous les caches le long du chemin de la réponse implémentent HTTP/1.1. Un cache MUST interpréter cette valeur par rapport à l'instant où la requête a été initiée, et non à l'instant où la réponse a été reçue.

apparent_age = max(0, response_time - date_value);

response_delay = response_time - request_time;
corrected_age_value = age_value + response_delay;

Ceux-ci sont combinés comme suit :

corrected_initial_age = max(apparent_age, corrected_age_value);

sauf si le cache a confiance dans la valeur du champ d'en-tête Age (par exemple, parce qu'il n'y a pas de sauts HTTP/1.0 dans le champ d'en-tête Via), auquel cas le corrected_age_value MAY être utilisé comme corrected_initial_age.

Le current_age d'une réponse stockée peut alors être calculé en ajoutant au corrected_initial_age la durée (en secondes) écoulée depuis que la réponse stockée a été validée pour la dernière fois par le serveur d'origine.

resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;

4.2.4. Fourniture de réponses périmées​

Une réponse « périmée » est une réponse qui, soit dispose d'informations d'expiration explicites, soit est autorisée à voir une expiration heuristique calculée, mais qui n'est pas fraîche selon les calculs de la Section 4.2.

Un cache MUST NOT générer une réponse périmée si cela est interdit par une directive explicite du protocole (par exemple, par une directive de cache « no-store » ou « no-cache », une directive de réponse de cache « must-revalidate », ou une directive de réponse de cache « s-maxage » ou « proxy-revalidate » applicable ; voir Section 5.2.2).

Un cache MUST NOT envoyer de réponses périmées, sauf s'il est déconnecté (c'est-à-dire s'il ne peut pas contacter le serveur d'origine ni trouver un chemin de transfert) ou si cela est explicitement autorisé (par exemple, par la directive de requête max-stale ; voir Section 5.2.1).

Un cache SHOULD générer dans les réponses périmées un champ d'en-tête Warning avec le warn-code 110 (voir Section 5.5.1). De même, un cache SHOULD générer un warn-code 112 (voir Section 5.5.3) dans les réponses périmées si le cache est déconnecté.

Un cache SHOULD NOT générer un nouveau champ d'en-tête Warning lorsqu'il transmet une réponse qui ne comporte pas de champ d'en-tête Age, même si la réponse est déjà périmée. Un cache n'a pas besoin de valider une réponse qui n'est devenue périmée qu'en transit.

4.3. Validation​

Lorsqu'un cache dispose d'une ou plusieurs réponses stockées pour un URI demandé, mais ne peut en servir aucune (par exemple, parce qu'elles ne sont pas fraîches, ou parce qu'aucune ne peut être sélectionnée ; voir Section 4.1), il peut utiliser le mécanisme de requête conditionnelle [RFC7232] dans la requête transmise pour donner au prochain serveur entrant l'occasion de sélectionner une réponse stockée valide à utiliser, en mettant à jour les métadonnées stockées au passage, ou de remplacer la ou les réponses stockées par une nouvelle réponse. Ce processus est appelé « validation » ou « revalidation » de la réponse stockée.

4.3.1. Envoi d'une requête de validation​

Lorsqu'il envoie une requête conditionnelle pour la validation du cache, un cache envoie un ou plusieurs champs d'en-tête de précondition contenant les métadonnées de validateur issues de sa ou de ses réponses stockées, que les destinataires comparent ensuite pour déterminer si une réponse stockée est équivalente à une représentation courante de la ressource.

L'un de ces validateurs est l'horodatage donné dans un champ d'en-tête Last-Modified (Section 2.2 du [RFC7232]), qui peut être utilisé dans un champ d'en-tête If-Modified-Since pour la validation de réponse, ou dans un champ d'en-tête If-Unmodified-Since ou If-Range pour la sélection de représentation (c'est-à-dire que le client se réfère spécifiquement à une représentation obtenue précédemment et portant cet horodatage).

Un autre validateur est l'étiquette d'entité donnée dans un champ d'en-tête ETag (Section 2.3 du [RFC7232]). Une ou plusieurs étiquettes d'entité, indiquant une ou plusieurs réponses stockées, peuvent être utilisées dans un champ d'en-tête If-None-Match pour la validation de réponse, ou dans un champ d'en-tête If-Match ou If-Range pour la sélection de représentation (c'est-à-dire que le client se réfère spécifiquement à une ou plusieurs représentations obtenues précédemment et portant les étiquettes d'entité énumérées).

4.3.2. Traitement d'une requête de validation reçue​

Chaque client de la chaîne de requêtes peut avoir son propre cache, de sorte qu'il est courant qu'un cache situé chez un intermédiaire reçoive des requêtes conditionnelles d'autres caches (sortants). De même, certains agents utilisateurs se servent de requêtes conditionnelles pour limiter les transferts de données aux représentations récemment modifiées ou pour achever le transfert d'une représentation partiellement récupérée.

Si un cache reçoit une requête qui peut être satisfaite en réutilisant l'une de ses réponses stockées 200 (OK) ou 206 (Partial Content), le cache SHOULD évaluer toutes les préconditions de champs d'en-tête conditionnels applicables reçues dans cette requête par rapport aux validateurs correspondants contenus dans la réponse sélectionnée. Un cache MUST NOT évaluer les champs d'en-tête conditionnels qui ne s'appliquent qu'à un serveur d'origine, qui se trouvent dans une requête dont la sémantique ne peut pas être satisfaite par une réponse mise en cache, ou qui s'appliquent à une ressource cible pour laquelle il n'a aucune réponse stockée ; de telles préconditions sont probablement destinées à quelque autre serveur (entrant).

L'évaluation correcte des requêtes conditionnelles par un cache dépend des champs d'en-tête de précondition reçus et de leur priorité, comme défini à la Section 6 du [RFC7232]. Les champs d'en-tête conditionnels If-Match et If-Unmodified-Since ne s'appliquent pas à un cache.

Une requête contenant un champ d'en-tête If-None-Match (Section 3.2 du [RFC7232]) indique que le client souhaite valider une ou plusieurs de ses propres réponses stockées par comparaison avec la réponse stockée que le cache sélectionne. Si la valeur du champ est « * », ou si la valeur du champ est une liste d'étiquettes d'entité et qu'au moins l'une d'elles correspond à l'étiquette d'entité de la réponse stockée sélectionnée, un destinataire de cache SHOULD générer une réponse 304 (Not Modified) (en utilisant les métadonnées de la réponse stockée sélectionnée) au lieu d'envoyer cette réponse stockée.

Lorsqu'un cache décide de revalider ses propres réponses stockées pour une requête contenant une liste d'étiquettes d'entité If-None-Match, le cache MAY combiner la liste reçue avec une liste d'étiquettes d'entité issues de son propre ensemble de réponses stockées (fraîches ou périmées) et envoyer l'union des deux listes comme valeur de remplacement du champ d'en-tête If-None-Match dans la requête transmise. Si une réponse stockée ne contient que du contenu partiel, le cache MUST NOT inclure son étiquette d'entité dans l'union, sauf si la requête porte sur une plage qui serait entièrement satisfaite par cette réponse stockée partielle. Si la réponse à la requête transmise est 304 (Not Modified) et comporte une valeur de champ d'en-tête ETag avec une étiquette d'entité qui ne figure pas dans la liste du client, le cache MUST générer une réponse 200 (OK) pour le client en réutilisant sa réponse stockée correspondante, telle que mise à jour par les métadonnées de la réponse 304 (Section 4.3.4).

Si aucun champ d'en-tête If-None-Match n'est présent, une requête contenant un champ d'en-tête If-Modified-Since (Section 3.3 du [RFC7232]) indique que le client souhaite valider une ou plusieurs de ses propres réponses stockées par date de modification. Un destinataire de cache SHOULD générer une réponse 304 (Not Modified) (en utilisant les métadonnées de la réponse stockée sélectionnée) si l'un des cas suivants est vrai : 1) la réponse stockée sélectionnée a une valeur de champ Last-Modified antérieure ou égale à l'horodatage conditionnel ; 2) aucun champ Last-Modified n'est présent dans la réponse stockée sélectionnée, mais celle-ci a une valeur de champ Date antérieure ou égale à l'horodatage conditionnel ; ou 3) ni Last-Modified ni Date ne sont présents dans la réponse stockée sélectionnée, mais le cache a enregistré qu'elle a été reçue à un instant antérieur ou égal à l'horodatage conditionnel.

Un cache qui implémente les réponses partielles aux requêtes de plage, comme défini dans le [RFC7233], doit également évaluer un champ d'en-tête If-Range reçu (Section 3.2 du [RFC7233]) par rapport à sa réponse stockée sélectionnée.

4.3.3. Traitement d'une réponse de validation​

Le traitement par le cache d'une réponse à une requête conditionnelle dépend de son code d'état :

  • Un code d'état de réponse 304 (Not Modified) indique que la réponse stockée peut être mise à jour et réutilisée ; voir Section 4.3.4.

  • Une réponse complète (c'est-à-dire comportant un corps de charge utile) indique qu'aucune des réponses stockées désignées dans la requête conditionnelle n'est appropriée. À la place, le cache MUST utiliser la réponse complète pour satisfaire la requête et MAY remplacer la ou les réponses stockées.

  • Toutefois, si un cache reçoit une réponse 5xx (Server Error) en tentant de valider une réponse, il peut soit transmettre cette réponse au client demandeur, soit agir comme si le serveur n'avait pas répondu. Dans ce dernier cas, le cache MAY envoyer une réponse précédemment stockée (voir Section 4.2.4).

4.3.4. Rafraîchissement des réponses stockées lors de la validation​

Lorsqu'un cache reçoit une réponse 304 (Not Modified) et dispose déjà d'une ou plusieurs réponses stockées 200 (OK) pour la même clé de cache, le cache doit identifier lesquelles des réponses stockées sont mises à jour par cette nouvelle réponse, puis mettre à jour la ou les réponses stockées avec les nouvelles informations fournies dans la réponse 304.

La réponse stockée à mettre à jour est identifiée en utilisant la première correspondance (le cas échéant) parmi les suivantes :

  • Si la nouvelle réponse contient un validateur fort (voir Section 2.1 du [RFC7232]), ce validateur fort identifie la représentation sélectionnée à mettre à jour. Toutes les réponses stockées ayant le même validateur fort sont sélectionnées. Si aucune des réponses stockées ne contient le même validateur fort, le cache MUST NOT utiliser la nouvelle réponse pour mettre à jour une quelconque réponse stockée.

  • Si la nouvelle réponse contient un validateur faible et que ce validateur correspond à l'une des réponses stockées du cache, la plus récente de ces réponses stockées correspondantes est sélectionnée pour mise à jour.

  • Si la nouvelle réponse ne comporte aucune forme de validateur (comme dans le cas où un client génère une requête If-Modified-Since à partir d'une source autre que le champ d'en-tête de réponse Last-Modified), qu'il n'y a qu'une seule réponse stockée, et que cette réponse stockée est également dépourvue de validateur, alors cette réponse stockée est sélectionnée pour mise à jour.

Si une réponse stockée est sélectionnée pour mise à jour, le cache MUST :

  • supprimer tous les champs d'en-tête Warning de la réponse stockée dont le warn-code est 1xx (voir Section 5.5) ;

  • conserver tous les champs d'en-tête Warning de la réponse stockée dont le warn-code est 2xx ; et,

  • utiliser les autres champs d'en-tête fournis dans la réponse 304 (Not Modified) pour remplacer toutes les occurrences des champs d'en-tête correspondants dans la réponse stockée.

4.3.5. Rafraîchissement des réponses via HEAD​

Une réponse à la méthode HEAD est identique à ce qu'aurait été une requête équivalente faite avec GET, à ceci près qu'elle est dépourvue de corps. Cette propriété des réponses HEAD peut être utilisée pour invalider ou mettre à jour une réponse GET mise en cache si le mécanisme plus efficace de requête GET conditionnelle n'est pas disponible (faute de validateurs présents dans la réponse stockée) ou si la transmission du corps de la représentation n'est pas souhaitée, même s'il a changé.

Lorsqu'un cache effectue une requête HEAD entrante pour une cible de requête donnée et reçoit une réponse 200 (OK), le cache SHOULD mettre à jour ou invalider chacune de ses réponses GET stockées qui auraient pu être sélectionnées pour cette requête (voir Section 4.1).

Pour chacune des réponses stockées qui auraient pu être sélectionnées, si la réponse stockée et la réponse HEAD ont des valeurs correspondantes pour tout champ de validateur reçu (ETag et Last-Modified) et, si la réponse HEAD comporte un champ d'en-tête Content-Length, que la valeur de Content-Length correspond à celle de la réponse stockée, le cache SHOULD mettre à jour la réponse stockée comme décrit ci-dessous ; sinon, le cache SHOULD considérer la réponse stockée comme périmée.

Si un cache met à jour une réponse stockée avec les métadonnées fournies dans une réponse HEAD, le cache MUST :

  • supprimer tous les champs d'en-tête Warning de la réponse stockée dont le warn-code est 1xx (voir Section 5.5) ;

  • conserver tous les champs d'en-tête Warning de la réponse stockée dont le warn-code est 2xx ; et,

  • utiliser les autres champs d'en-tête fournis dans la réponse HEAD pour remplacer toutes les occurrences des champs d'en-tête correspondants dans la réponse stockée et ajouter les nouveaux champs d'en-tête à la section d'en-tête de la réponse stockée, sauf restriction contraire du champ d'en-tête Cache-Control.

4.4. Invalidation​

Parce que les méthodes de requête non sûres (Section 4.2.1 du [RFC7231]) telles que PUT, POST ou DELETE sont susceptibles de modifier l'état du serveur d'origine, les caches intermédiaires peuvent les utiliser pour tenir leur contenu à jour.

Un cache MUST invalider l'URI de requête effective (Section 5.5 du [RFC7230]) ainsi que la ou les URI figurant dans les champs d'en-tête de réponse Location et Content-Location (si présents) lorsqu'un code d'état sans erreur est reçu en réponse à une méthode de requête non sûre.

Toutefois, un cache MUST NOT invalider une URI issue d'un champ d'en-tête de réponse Location ou Content-Location si la partie hôte de cette URI diffère de la partie hôte de l'URI de requête effective (Section 5.5 du [RFC7230]). Cela aide à prévenir les attaques par déni de service.

Un cache MUST invalider l'URI de requête effective (Section 5.5 du [RFC7230]) lorsqu'il reçoit une réponse sans erreur à une requête dont la méthode est de sûreté inconnue.

Ici, une « réponse sans erreur » est une réponse dont le code d'état est 2xx (Successful) ou 3xx (Redirection). « Invalider » signifie que le cache supprimera toutes les réponses stockées liées à l'URI de requête effective, ou les marquera comme « invalides » et nécessitant une validation obligatoire avant de pouvoir être envoyées en réponse à une requête ultérieure.

Notez que cela ne garantit pas que toutes les réponses appropriées soient invalidées. Par exemple, une requête modifiant l'état peut invalider des réponses dans les caches qu'elle traverse, mais les réponses pertinentes peuvent encore être stockées dans d'autres caches qu'elle n'a pas traversés.