207

I read about Pragma header on Wikipedia which says:

"The Pragma: no-cache header field is an HTTP/1.0 header intended for use in requests. It is a means for the browser to tell the server and any intermediate caches that it wants a fresh version of the resource, not for the server to tell the browser not to cache the resource. Some user agents do pay attention to this header in responses, but the HTTP/1.1 RFC specifically warns against relying on this behavior."

But I haven't understood what it does? What is the difference between the Cache-Control header whose value is no-cache and Pragma whose value is also no-cache?

Luke Girvin
  • 13,221
  • 9
  • 64
  • 84
saplingPro
  • 20,769
  • 53
  • 137
  • 195

3 Answers3

243

Pragma is the HTTP/1.0 implementation and cache-control is the HTTP/1.1 implementation of the same concept. They both are meant to prevent the client from caching the response. Older clients may not support HTTP/1.1 which is why that header is still in use.

Shashank Agrawal
  • 25,161
  • 11
  • 89
  • 121
Anna Brenden
  • 3,837
  • 2
  • 21
  • 19
  • 41
    Although the answer of cnst below is much more complicated, it is also much more correct according to the specification. `Pragma: no-cache` is intended to be used only in requests (meaning "I want the original, not a cached copy") and its behaviour is not specified for responses. – clime Mar 07 '13 at 13:49
  • 8
    `Cache-Control: no-cache` has the same meaning for requests but is actually also defined for responses, meaning "If you want to use a cached copy of this in future, you must first check with me that it is up-to-date (i.e. perform revalidation)". – clime Mar 07 '13 at 14:03
  • 3
    It is for Cache Control, it does not have to be ONLY for cache-preventing, it can also be used to say "You can cache this." .... – jave.web Jan 21 '15 at 10:01
  • Basic answer. To get it more complicated: It's also a request header which means you can send no-cache to the server too. And that actually might mean to returning stale content to the clients, WHAT?? Now you forget this and read the above simple answer and enjoy your life, don't dig it too hard lol – yakya Mar 03 '16 at 21:29
  • _They both are meant to prevent the client from caching the response_ is a confusing note for readers. It can also have `max-age` which doesn't prevent caching. It just sets an expiration date for it... – mfaani Oct 23 '18 at 17:47
  • @clime cache-control: no-cache doesn't have same meaning. `The no-cache directive means that a browser may cache a response, but must first submit a validation request ` cache-control: no-store is the one that has the same meaning. – Alan Deep Mar 12 '22 at 03:58
108

There is no difference, except that Pragma is only defined as applicable to the requests by the client, whereas Cache-Control may be used by both the requests of the clients and the replies of the servers.

So, as far as standards go, they can only be compared from the perspective of the client making a requests and the server receiving a request from the client. The http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32 defines the scenario as follows:

HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in 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

The way I would read the above:

  • if you're writing a client and need no-cache:

    • just use Pragma: no-cache in your requests, since you may not know if Cache-Control is supported by the server;
    • but in replies, to decide on whether to cache, check for Cache-Control

  • if you're writing a server:

    • in parsing requests from the clients, check for Cache-Control; if not found, check for Pragma: no-cache, and execute the Cache-Control: no-cache logic;
    • in replies, provide Cache-Control.

Of course, reality might be different from what's written or implied in the RFC!

cnst
  • 25,870
  • 6
  • 90
  • 122
  • 5
    What if the header has both? `Cache-Control: max-age=86400` and `Pragma: no-cache`? Which one will then be honored by the modern browsers? – PKHunter Feb 14 '17 at 11:52
  • 3
    @PKHunter, why would you care which way it goes if the behaviour is undefined? If you're responsible for the server, clearly you can do better than give out misleading information to the client. Also, as pointed in my answer, the `Pragma: no-cache` is only defined for requests from the browser, and it would thus be entirely invalid and undefined in replies from the server to the browser, e.g., I'd imagine that every single browser (whether modern or not) should ignore such a header in any reply it may receive. – cnst Feb 21 '17 at 20:06
  • 3
    A modern browser should ignore the Pragma in favor of Cache-Control if both are present because the latter can specify time periods and other information that was not available in the initial 1.0 protocol. – Randall Borck Apr 05 '18 at 14:54
29
Stop using (HTTP 1.0) Replaced with (HTTP 1.1 since 1999)
Expires: [date] Cache-Control: max-age=[seconds]
Pragma: no-cache Cache-Control: no-cache

If it's after 1999, and you're still using Expires or Pragma, you're doing it wrong.

I'm looking at you 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: Pragma is a legacy of HTTP/1.0 and hasn't been needed since Internet Explorer 5, or Netscape 4.7. Unless you expect some of your users to be using IE5: it's safe to stop using it.

  • Expires: [date] (deprecated - HTTP 1.0)
  • Pragma: no-cache (deprecated - HTTP 1.0)
  • Cache-Control: max-age=[seconds]
  • Cache-Control: no-cache (must re-validate the cached copy every time)

And the conditional requests:

  • Etag (entity tag) based conditional requests
    • Server: Etag: W/“1d2e7–1648e509289”
    • Client: If-None-Match: W/“1d2e7–1648e509289”
    • Server: 304 Not Modified
  • Modified date based conditional requests
    • Server: last-modified: Thu, 09 May 2019 19:15:47 GMT
    • Client: If-Modified-Since: Fri, 13 Jul 2018 10:49:23 GMT
    • Server: 304 Not Modified

last-modified: Thu, 09 May 2019 19:15:47 GMT

Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
  • 2
    The RFC says you should use them both in case a client doesn't support Cache-Control: https://tools.ietf.org/html/rfc7234#page-29 – Randall Borck Apr 05 '18 at 14:55
  • 3
    The *client* *"ought to"* include both - unless it wants to treat HTTP/1.1 and HTTP/1.0 caching servers differently. The server should not include `Pragma` at all. *(In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification deprecates such extensions to improve interoperability.)* – Ian Boyd Apr 05 '18 at 15:04
  • 2
    From a security standpoint, it is recommended to use it. Many browsers follow the pragma: no-cache directive, so it is advised to use it by OWASP: https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#How_do_I_ensure_that_sensitive_pages_are_not_cached_on_the_user.27s_browser.3F – Randall Borck Apr 27 '18 at 18:42
  • 5
    @RandallBorck: You are spreading outdated (by two decades, no less!) information. *No* browsers follow the Pragma directive any more, unless it's 1999. This is cargo cult advice: "it doesn't hurt and we've always done it, therefore it's good and necessary." – Piskvor left the building Mar 05 '19 at 14:47
  • 3
    @Piskvor Most servers still support both 1.0 and 1.1, so unless you actively block HTTP/1.0 requests you don't choose which protocol the client is using. Most developers today don't bother to block 1.0, hence it is still a best practice, even in 2019. – Randall Borck Mar 08 '19 at 19:24
  • 1
    I'm confused how it can be "best practice" while doing virtually nothing. In what case would this header have any effect, @RandallBorck? It seems like if a user is already using an ancient, unsupported browser it's already going to be riddled with security holes, so why spend money and time talking about and implementing this? "It's easy to do" is not a good reason to do something useless. – DavidS Jun 29 '20 at 22:41
  • 3
    @DavidS if you are actively blocking HTTP/1.0, then just use Cache-Control. If you allow HTTP/1.0 requests then it is also your responsibility to follow the security best practices for that protocol and include the Pragma header too. If you don't know that you can block HTTP/1.0, then design your site to support it. I don't think there is anything wrong with blocking HTTP/1.0 and dropping the header, but if you advertise and serve a client protocol you have a due diligence obligation to make it secure for that client, even if you don't like their choice of protocol. – Randall Borck Oct 26 '20 at 15:20
  • 1
    SO has stopped serving Pragma and now solely relies on cache-control. – Jonathan Arbely Apr 04 '22 at 21:49