I've been investigating the Pragma header, since there are already two other cache-busting HTTP response headers (Cache-Control & Expires), and I was interested in which browsers use(d) the old HTTP 1.0 one.

It turns out the spec only defines Pragma behavior (no-cache) for HTTP 1.0 requests, not responses.

The only specific browser mentions I can find is for IE4, which seems to require 32 KB of content before honoring it as a <meta> element, meaning that as a header it never worked even when that browser was relevant, and Netscape 4 which apparently also didn't work.

OWASP seems to be recommending this header, and a few big sites use it, but it seems a lot like it got started as a "just in case", was never actually supported, and perpetuated as a superstition.

Has anyone observed a reproducible (and desirable) change in behavior by using the Pragma HTTP header in a response, distinct from the functionality of Cache-Control or Expires?

  • stackoverflow.com/questions/10314174/…
    – smali
    Commented Apr 22, 2015 at 5:09
  • @ali786 The accepted answer for that question is wrong, and the other focuses only on the correct usage of the header. I'm interested in real software examples where implementors may have misread the spec and a response's Pragma header has a different effect than the Cache-Control or Expires headers. OWASP is recommending it as a response header —but is there any reason to?
    – brianary
    Commented Apr 22, 2015 at 5:22
  • In it's possible role in informing caching behavior for proxies along the communication path, it seem reasonable to think that the server might want to ensure a particular kind of response not be cached.... regardless of the state of that 'thinking' at the time of the request. Is that the kind of thing that you mean?
    – Rondo
    Commented Apr 24, 2015 at 5:23
  • @Rondo No. I'm trying to tell if the Pragma header in particular achieves that need, any more than the Cache-Control or Expires headers already do, or if it's just being employed superstitiously.
    – brianary
    Commented Apr 24, 2015 at 5:37
  • @brianary My understanding is that with HTTP/1.0 responses, no-cache and no-store Cache-Control directives are ignored in some browsers like older IE versions (8, 9 ish) and that Pragma no-cache works, but only with SSL connections in ie8 and early ie9.
    – Rondo
    Commented Apr 25, 2015 at 2:05

1 Answer 1


Pragma is deprecated in favor of Cache-Control, but because of its common misuse as a response header there are clients and proxies who will interpret it as such.

Past squid versions are an example and starting with 3.2, Squid is advertising and attempting to fully support HTTP/1.1 specifications meaning pragma in a server response has no meaning whatsoever and will be ignored.

According to Microsoft KB234067, Internet Explorer 4.01 and 6.0 allow Pragma: no-cache in a secure HTTP response and a Pragma: no-cache meta tag via insecure response. Other browsers such as Firefox seem to have spotty support of it.

Note RFC2616 states:

Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.

Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see section 14.32).

  • 1
    It looks like IE4, IE6, and pre-3.2 Squid all supported Cache-Control though, so Pragma still wouldn't be necessary for them, or represent distinct behavior. (I've added some clarification to the question.)
    – brianary
    Commented Apr 22, 2015 at 14:40
  • 1
    This shows the problem with the stupid auto-awarding bounty system. This does not answer the question of whether Pragma is necessary. I suspect those voting it up didn't fully read the question.
    – brianary
    Commented May 4, 2015 at 21:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .