4.3.3. Handling a Validation Response (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 une avec 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. Au lieu de cela, le cache DOIT (MUST) utiliser la réponse complète pour satisfaire la requête. Le cache PEUT (MAY) stocker une telle réponse, sous réserve de ses contraintes (voir Section 3).
Cependant, 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éussi à répondre. Dans ce dernier cas, le cache PEUT (MAY) envoyer une réponse précédemment stockée (voir Section 4.2.4).

4.3.4. Freshening Stored Responses upon Validation (Actualisation des réponses stockées lors de la validation)

Lorsqu'un cache reçoit une réponse 304 (Not Modified), il DOIT (MUST) mettre à jour les champs d'en-tête de la réponse stockée avec les champs d'en-tête fournis dans la réponse 304, conformément à RFC 7232, Section 4.1.

Le cache DOIT (MUST) également utiliser la réponse stockée mise à jour pour satisfaire la requête qui a causé la validation et PEUT (MAY) l'utiliser pour satisfaire d'autres requêtes.

Lors de la mise à jour d'une valeur de champ d'en-tête, le cache DOIT (MUST) supprimer tout champ d'en-tête Warning dans la réponse stockée avec warn-code 1xx (voir Section 5.5) et DOIT (MUST) ajouter à la réponse stockée mise à jour tous les champs d'en-tête Warning dans la réponse 304.

4.3.5. Freshening Responses via HEAD (Actualisation 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, sauf qu'elle manque un corps. Cette propriété des réponses HEAD permet à un cache de mettre à jour une réponse stockée sans transférer l'intégralité du contenu de la réponse. Par conséquent, un cache PEUT (MAY) utiliser une réponse HEAD pour mettre à jour une réponse GET en cache si la réponse HEAD a une ou des valeurs de champ Last-Modified et/ou ETag qui correspondent à celles de la réponse GET stockée.

Lors de la mise à jour d'une réponse stockée à l'aide d'une réponse HEAD, le cache DOIT (MUST) mettre à jour les champs d'en-tête de la réponse stockée avec les valeurs de champ d'en-tête fournies dans la réponse HEAD.

4.4. Invalidation

Le but de l'invalidation de cache est d'éliminer les réponses dont la valeur de réponse réelle (et non les champs d'en-tête) est susceptible d'être significativement différente de la réponse invalidée, évitant ainsi toute confusion si les deux sont présentées comme alternatives.

Lorsqu'un cache reçoit une requête avec une méthode qui peut entraîner une mise à jour des réponses stockées (par exemple, PUT, POST ou DELETE ; voir Section 4.2.1 de [RFC7231]), il DOIT (MUST) considérer toutes les réponses stockées pour l'URI de requête effective (Section 5.5 de [RFC7230]) comme invalidées, ainsi que celles pour les URI dans les champs d'en-tête de réponse Location et Content-Location (s'ils sont présents).

Cependant, un cache NE DOIT PAS (MUST NOT) invalider un URI qui apparaît dans les champs d'en-tête de réponse Location ou Content-Location si le code d'état de réponse est une redirection et que le composant hôte dans cet URI diffère de l'hôte de l'URI de requête effective.

Un cache DOIT (MUST) invalider l'URI de requête effective (Section 5.5 de [RFC7230]) lorsqu'il reçoit une réponse non-erreur à une requête avec une méthode dont la sémantique implique que l'état de la ressource cible pourrait avoir été modifié (par exemple, PUT, POST, DELETE et PATCH).