Vary
Baseline Widely available
This feature is well established and works across many devices and browser versions. It’s been available across browsers since July 2015.
L'en-tête HTTP Vary détermine comment les en-têtes de requêtes futures sont associés pour décider si une réponse en cache peut être réutilisée plutôt que de solliciter à nouveau le serveur d'origine. Il est utilisé par le serveur pour indiquer quels en-têtes sont utilisés pour représenter une resource dans un algorithme de négociation de contenu.
L'en-tête Vary doit être renseigné de manière identique sur une réponse 304 Not Modified à ce qu'elle aurait été sur la réponse 200 OK correspondante.
| Type d'en-tête | Response header |
|---|---|
| Forbidden header name | non |
Syntaxe
Vary: * Vary: <header-name>, <header-name>, ...
Directives
- *
-
Chaque requête pour une URL doit être traitée comme une requête unique à ne pas mettre en cache. Une meilleure manière de l'indiquer est d'utiliser
Cache-Control: private, qui est plus clair à lire et signale aussi que l'objet ne doit jamais être mis en cache. - <header-name>
-
Une liste séparé par des virgules de noms d'en-tête à prendre en compte lorsqu'il est décidé si une réponse en cache peut être utilisée ou non.
Examples
Service dynamique
Lorsque l'en-tête Vary: User-Agent est utilisée, les serveurs de cache doivent prendre en compte l'agent de l'utilisateur pour décider de servir la page depuis le cache ou non. Par exemple, si vous servez du contenu différent pour les utilisateurs sur mobile, il aide à éviter qu'une version ordinateur de votre site ne soit distribuée à un utilisateur sur mobile. Il peut aider google et d'autres moteurs de recherche à prendre en compte la version pour mobile d'un site, ainsi que de signaler que le Cloaking n'est pas intentionel.
Vary: User-Agent
Spécifications
| Specification |
|---|
| HTTP Semantics # field.vary |
Compatibilité des navigateurs
BCD tables only load in the browser