Pourquoi l’atsortingbut Cache-Control est-il envoyé dans l’en-tête de requête (client à serveur)?

Après avoir lu le champ Cache-Control de l’en-tête HTTP,

Je comprends que le champ Cache-Control dans l’en-tête de réponse HTTP (serveur à client) spécifie les directives du serveur proxy intermédiaire / navigateur Web sur la gestion de la réponse, en envoyant des valeurs différentes pour le champ Cache-Control : private , public , no-cache ou no-store dans l’en-tête de réponse.

Mais je ne comprends pas pourquoi nous devons envoyer l’atsortingbut Cache-Control dans l’en-tête de la requête (client à serveur)?

Cache-Control: no-cache est 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 demande au serveur, les mandataires intermédiaires renverront une copie du contenu s’il est frais (il n’a pas expiré selon les Expire ou max-age ). Cache-Control demande à ces mandataires de revalider la copie même si elle est fraîche.

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

En plus de la réponse ci-dessus,
Il pourrait y avoir une configuration où le chaînage du cache est implémenté. Dans ce cas, si la requête arrive en premier dans le cache où elle n’est pas satisfaite, elle pourrait aller dans un autre cache en chaîne.

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