4.3. Validation (Validation)
Lorsqu'un cache possède 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 qu'une directive de requête l'interdit), il peut utiliser le mécanisme de requête conditionnelle [RFC7232] dans la requête transmise pour donner au serveur d'origine l'opportunité de sélectionner une réponse stockée valide à utiliser, en mettant à jour les métadonnées stockées dans le processus, ou de remplacer la ou les réponses stockées par une nouvelle réponse. Ce processus est connu sous le nom de "validation" ou "revalidation" de la réponse stockée.
4.3.1. Envoi d'une requête de validation (Sending a Validation Request)
Lors de la génération d'une requête conditionnelle pour validation, un cache commence soit avec une requête qu'il tente de satisfaire, soit (s'il initie la requête de manière indépendante) synthétise une requête en utilisant une réponse stockée en copiant la méthode, l'URI cible et les champs d'en-tête de requête pertinents.
Il met ensuite à jour cette requête avec un ou plusieurs champs d'en-tête de précondition. Ceux-ci contiennent des métadonnées de validateur (Section 2.3 de [RFC7232]) extraites de la ou des réponses stockées en cours de validation. En général, cela inclura les valeurs des champs Last-Modified et/ou ETag de la réponse stockée.
Le cache peut ensuite envoyer la requête conditionnelle au serveur d'origine (ou, potentiellement, à un cache en aval répertorié dans un champ d'en-tête Via).
4.3.2. Gestion d'une requête de validation reçue (Handling a Received Validation Request)
Chaque client dans la chaîne de requêtes peut avoir son propre cache, il est donc courant qu'un cache à un intermédiaire reçoive des requêtes conditionnelles d'autres caches (sortants). De même, certains clients peuvent avoir une désynchronisation d'horloge ou d'autres problèmes qui les amènent à générer des requêtes conditionnelles sans les comprendre, ou de telles requêtes peuvent être générées par une implémentation qui utilise des bibliothèques HTTP sous-jacentes.
Cela signifie que servir une réponse 304 (Not Modified) ou 412 (Precondition Failed) à une requête conditionnelle ne peut pas être supposé impliquer que le client comprend de telles réponses, ou qu'il a une copie en cache (même s'il en a une, elle pourrait avoir été supprimée).
Lorsqu'un cache reçoit une requête qui inclut un champ de validateur (tel qu'un champ d'en-tête If-None-Match), il NE DOIT PAS (MUST NOT) renvoyer une réponse 304 (Not Modified) à moins qu'il ne soit certain que la réponse stockée qui est le sujet de la requête conditionnelle est la réponse de validation la plus récente reçue de l'amont. En particulier, les intermédiaires doivent vérifier que les validateurs de la réponse stockée (valeurs des champs ETag et Last-Modified, si présents) sont identiques octet par octet à ceux présentés dans la requête conditionnelle.
Notez qu'un cache n'est pas tenu d'effectuer une telle vérification lorsqu'il n'a pas de réponse stockée (c'est-à-dire qu'il effectue une mise en cache "à la demande").
Un cache NE DOIT PAS (MUST NOT) envoyer une réponse 304 (Not Modified) en réponse à une requête qui contient un champ d'en-tête de précondition If-None-Match ou If-Modified-Since dont la condition s'évalue à faux, car le client ne serait pas en mesure de construire une réponse valide à partir de la réponse stockée du cache.
Au lieu de cela, un cache qui reçoit une requête conditionnelle et qui a une réponse stockée qui convient pour servir en réponse, soit :
- enverra une réponse 304 (Not Modified) si la réponse stockée est fraîche (Section 4.2), ou si elle a été validée avec succès (Section 4.3), ou
- transmettra la requête vers le serveur d'origine avec sa propre requête conditionnelle qui tente de valider la réponse stockée.
Dans ce dernier cas, le cache inclura un validateur dans la requête transmise. La requête transmise DOIT (MUST) utiliser l'ensemble le plus récent de validateurs associés à la réponse stockée.