Mise en cache par proxy HTTP pour les URL avec chaînes de requête
Donnez aux ressources fondées sur des requêtes une politique de cache réfléchie tout en conservant les valeurs de leurs paramètres dans la clé de cache.
Une chaîne de requête ne rend pas une réponse non cachable selon les règles modernes de HTTP. Une ressource publique telle que /catalog?page=2 peut déclarer directement sa fraîcheur prévue :
Cache-Control: public, max-age=60Il s'agit d'une politique illustrative pour du contenu public. La réponse doit encore satisfaire les autres exigences de cachabilité. Les résultats personnalisés ne devraient pas obtenir un cache partagé simplement parce qu'un opérateur de proxy souhaite un meilleur taux de succès.
La requête reste une partie de l'URI cible utilisée dans la clé de cache. La page 2 et la page 3 sont des requêtes différentes. Supprimer la requête pour que leurs URL se ressemblent peut servir un résultat à la place de l'autre ; cela ne rend pas les résultats équivalents.
L'ancienne restriction de HTTP sur la fraîcheur heuristique pour les URL avec requête a été supprimée après s'être révélée mal implémentée. La fraîcheur explicite évite de dépendre d'une estimation du cache, tandis que les règles locales du proxy peuvent toujours exclure certaines URL.
Le trafic HTTPS CONNECT ordinaire laisse la ressource et sa politique de cache à l'intérieur de TLS. Le proxy de transfert en tunnel n'obtient pas de cache d'objets pour ces pages simplement parce que l'URL utilise une requête.