Pourquoi l'attribut Cache-Control est-il envoyé dans l'en-tête de la requête (client vers serveur)?

Après avoir lu le Cache-Controlchamp de l'en-tête HTTP,

Je comprends que le Cache-Controlchamp dans l' en- tête de réponse HTTP (serveur client) spécifie les directives pour le navigateur des serveurs proxy intermédiaires / client sur la façon de gérer la réponse, en envoyant des valeurs différentes pour le Cache-Controlchamp: private, public, no-cacheou no-storedans l' en- tête de réponse.

Mais je ne comprends pas pourquoi avons-nous besoin d'envoyer l' Cache-Controlattribut dans l'en-tête de la demande (client à serveur)?

Cache-Control: no-cacheest généralement utilisé dans un en-tête de requête (envoyé du navigateur Web au serveur) pour forcer la validation de la ressource dans les proxys intermédiaires. Si le client n'envoie pas cette requête au serveur, les proxys intermédiaires renverront une copie du contenu s'il est frais (n'a pas expiré selon les champs Expireou max-age). Cache-Controlordonne à ces mandataires de revalider la copie même si elle est fraîche.

Un client peut envoyer un en- Cache-Controltête dans une demande afin de demander un comportement de mise en cache spécifique, tel que la revalidation, au serveur d'origine et à tout serveur proxy intermédiaire le long du chemin de la demande.

En plus de la réponse ci-dessus,
il peut y avoir une configuration où le chaînage du cache est implémenté. Dans ce cas, si la demande arrive au premier cache où elle n'est pas satisfaite, elle peut aller vers un cache chaîné plus loin.

Ainsi, afin d'obtenir toujours la réponse du serveur, nous incluons le contrôle du cache dans les en-têtes de requête. Cela garantira que la réponse provient toujours du serveur.