Pourquoi l'attribut Cache-Control est-il envoyé dans l'en-tête de la demande (client à serveur)?
Après avoir lu à propos du champ Cache-Control De l’en-tête HTTP,
Je comprends que le champ Cache-Control De l’en-tête de la réponse HTTP (serveur à client) spécifie les directives du navigateur client/proxy proxy sur la façon de traiter la réponse, en envoyant des valeurs différentes pour le paramètre Cache-Control]: private, public, no-cache ou no-store dans l'en-tête de la réponse.
Mais je ne comprends pas pourquoi devons-nous envoyer l'attribut Cache-Control Dans l'en-tête de la demande (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 mandataires intermédiaires. Si le client n'envoie pas cette requête au serveur, les mandataires intermédiaires renverront une copie du contenu s'il est récent (n'a pas expiré conformément à Expire ou max-age des champs). Cache-Control ordonne à ces mandataires de revalider la copie, même si elle est récente.
Un client peut envoyer un Cache-Control en-tête dans une requête afin de demander un comportement de mise en cache spécifique, tel qu'une revalidation, du serveur Origin et de tout serveur proxy intermédiaire le long du chemin de requête.
En plus de la réponse ci-dessus,
Il peut y avoir une configuration dans laquelle le chaînage de cache est implémenté. Dans ce cas, si la demande arrive dans le premier cache où elle n'est pas satisfaite, elle risque de passer à un cache plus chaîné.
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.