Différence entre les en-têtes Pragma et Cache-Control?

166

J'ai lu sur l'en- tête Pragma sur Wikipedia qui dit:

"Le champ d'en-tête Pragma: no-cache est un en-tête HTTP / 1.0 destiné à être utilisé dans les requêtes. C'est un moyen pour le navigateur d'indiquer au serveur et aux caches intermédiaires qu'il souhaite une nouvelle version de la ressource, pas pour le serveur pour dire au navigateur de ne pas mettre en cache la ressource. Certains agents utilisateurs font attention à cet en-tête dans les réponses, mais la RFC HTTP / 1.1 met en garde spécifiquement contre l'utilisation de ce comportement. "

Mais je n'ai pas compris ce que ça fait? Quelle est la différence entre l'en- Cache-Controltête dont la valeur est no-cacheet Pragmadont la valeur est également no-cache?

http http-headers request protocols httpresponse saplingPro
la source

Réponses:

196

Pragmaest l'implémentation HTTP / 1.0 et cache-controlest l'implémentation HTTP / 1.1 du même concept. Ils sont tous deux destinés à empêcher le client de mettre la réponse en cache. Les clients plus anciens peuvent ne pas prendre en charge HTTP / 1.1, c'est pourquoi cet en-tête est toujours utilisé.

Eric Brenden
la source

Bien que la réponse de cnst ci-dessous soit beaucoup plus compliquée, elle est également beaucoup plus correcte selon la spécification. Pragma: no-cacheest destiné à être utilisé uniquement dans les requêtes (ce qui signifie «Je veux l'original, pas une copie en cache») et son comportement n'est pas spécifié pour les réponses.

clime

Cache-Control: no-cachea la même signification pour les requêtes mais est en fait également définie pour les réponses, ce qui signifie "Si vous souhaitez utiliser une copie en cache de ceci à l'avenir, vous devez d'abord vérifier avec moi qu'elle est à jour (c'est-à-dire effectuer une revalidation)".

clime

C'est pour le contrôle du cache, il ne doit pas être UNIQUEMENT pour empêcher le cache, il peut également être utilisé pour dire "Vous pouvez mettre cela en cache". ....

jave.web

Réponse de base. Pour compliquer les choses: c'est aussi un en-tête de requête, ce qui signifie que vous pouvez également envoyer sans cache au serveur. Et cela pourrait signifier renvoyer du contenu périmé aux clients, QUOI ?? Maintenant, vous oubliez cela et lisez la réponse simple ci-dessus et profitez de votre vie, ne creusez pas trop fort lol

sotn

Ils sont tous deux destinés à empêcher le client de mettre en cache la réponse est une note déroutante pour les lecteurs. Il peut également avoir max-agece qui n'empêche pas la mise en cache. Il fixe juste une date d'expiration pour cela ...

Honey

Il n'y a pas de différence, sauf que cela Pragman'est défini que comme applicable aux demandes du client, alors qu'il Cache-Controlpeut être utilisé à la fois par les demandes des clients et les réponses des serveurs.

Ainsi, en ce qui concerne les normes, elles ne peuvent être comparées que du point de vue du client faisant une demande et du serveur recevant une demande du client. Le http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32 définit le scénario comme suit:

Les caches HTTP / 1.1 DEVRAIENT traiter "Pragma: no-cache" comme si le client avait envoyé "Cache-Control: no-cache". Aucune nouvelle directive Pragma ne sera définie dans HTTP.
  Note: because the meaning of "Pragma: no-cache as a response
  header field is not actually specified, it does not provide a
  reliable replacement for "Cache-Control: no-cache" in a response

La façon dont je lirais ce qui précède:

si vous écrivez un client et avez besoin no-cache:
- utilisez simplement Pragma: no-cachedans vos requêtes, car vous ne savez peut-être pas si Cache-Controlest pris en charge par le serveur;
- mais dans les réponses, pour décider de mettre en cache, vérifiez Cache-Control
si vous écrivez un serveur:
- dans l'analyse des demandes des clients, vérifiez Cache-Control; s'il n'est pas trouvé, vérifiez Pragma: no-cacheet exécutez la Cache-Control: no-cachelogique;
- dans les réponses, fournissez Cache-Control.

Bien sûr, la réalité peut être différente de ce qui est écrit ou implicite dans la RFC!

cnst
la source

Et si l'en-tête a les deux? Cache-Control: max-age=86400et Pragma: no-cache? Lequel sera alors honoré par les navigateurs modernes?

PKHunter

@PKHunter, pourquoi vous souciez-vous de la direction que cela prend si le comportement n'est pas défini? Si vous êtes responsable du serveur, vous pouvez clairement faire mieux que de donner des informations trompeuses au client. De plus, comme indiqué dans ma réponse, le Pragma: no-cachen'est défini que pour les demandes du navigateur, et il serait donc entièrement invalide et indéfini dans les réponses du serveur au navigateur, par exemple, j'imagine que chaque navigateur (qu'il soit moderne ou not) devrait ignorer un tel en-tête dans toute réponse qu'il pourrait recevoir.

cnst

Un navigateur moderne devrait ignorer le Pragma en faveur de Cache-Control si les deux sont présents car ce dernier peut spécifier des périodes et d'autres informations qui n'étaient pas disponibles dans le protocole initial 1.0.

Randall Borck

| Stop using          | Replaced with                    |
| (HTTP 1.0)          | (HTTP 1.1 - 1999)                |
|---------------------|----------------------------------|
| Expires: [date]     | Cache-Control: max-age=[seconds] |
| Pragma: no-cache    | Cache-Control: no-cache          |

Si c'est après 1999 et que vous utilisez toujours Expires ou Pragma , vous le faites mal.

Je vous regarde Stackoverflow:

200 OK
Pragma: no-cache
Content-Type: application/json
X-Frame-Options: SAMEORIGIN
X-Request-Guid: a3433194-4a03-4206-91ea-6a40f9bfd824
Strict-Transport-Security: max-age=15552000
Content-Length: 54
Accept-Ranges: bytes
Date: Tue, 03 Apr 2018 19:03:12 GMT
Via: 1.1 varnish
Connection: keep-alive
X-Served-By: cache-yyz8333-YYZ
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1522782193.766958,VS0,VE30
Vary: Fastly-SSL
X-DNS-Prefetch-Control: off
Cache-Control: private

tl; dr: Pragmaest un héritage de HTTP / 1.0 et n'est plus nécessaire depuis Internet Explorer 5 ou Netscape 4.7. Sauf si vous vous attendez à ce que certains de vos utilisateurs utilisent IE5: il est prudent de cesser de l'utiliser.

Expire: [date] (obsolète - HTTP 1.0)
Pragma: no-cache (obsolète - HTTP 1.0)
Contrôle du cache: max-age =[seconds]
Cache-Control: pas de cache (doit re-valider la copie mise en cache à chaque fois)

Et les requêtes conditionnelles:

Requêtes conditionnelles basées sur Etag (balise d'entité)
- Serveur: Etag: W/“1d2e7–1648e509289”
- Client: If-None-Match: W/“1d2e7–1648e509289”
- Serveur: 304 Not Modified
Demandes conditionnelles basées sur la date de modification
- Serveur: last-modified: Thu, 09 May 2019 19:15:47 GMT
- Client: If-Modified-Since: Fri, 13 Jul 2018 10:49:23 GMT
- Serveur: 304 Not Modified

Dernière modification: Jeu 09 mai 2019 19:15:47 GMT

Ian Boyd
la source

La RFC dit que vous devriez les utiliser tous les deux au cas où un client ne prend pas en charge Cache-Control: tools.ietf.org/html/rfc7234#page-29

Randall Borck

Le client "devrait" inclure les deux - à moins qu'il ne veuille traiter différemment les serveurs de cache HTTP / 1.1 et HTTP / 1.0. Le serveur ne doit pas du tout inclure Pragma. (Dans HTTP / 1.0, Pragma était défini comme un champ extensible pour les directives d'implémentation spécifiées pour les destinataires. Cette spécification désapprouve ces extensions pour améliorer l'interopérabilité.)

Ian Boyd

D'un point de vue de sécurité, il est recommandé de l'utiliser. De nombreux navigateurs suivent la directive pragma: no-cache, il est donc conseillé de l'utiliser par OWASP: owasp.org/index.php/…

Randall Borck

@RandallBorck: Vous diffusez des informations obsolètes (de deux décennies, pas moins!). Aucun navigateur ne suit plus la directive Pragma, sauf si nous sommes en 1999. C'est un conseil culte du cargo: "ça ne fait pas de mal et nous l'avons toujours fait, donc c'est bien et nécessaire."

Piskvor a quitté le bâtiment

@Piskvor La plupart des serveurs prennent toujours en charge la version 1.0 et 1.1, donc à moins que vous ne bloquiez activement les requêtes HTTP / 1.0, vous ne choisissez pas le protocole utilisé par le client. Aujourd'hui, la plupart des développeurs ne prennent pas la peine de bloquer la version 1.0, c'est donc toujours une bonne pratique, même en 2019.

Randall Borck