11

We're currently reviewing our set of "no-cache" security headers:

  • Cache-Control "no-cache, no-store, must-revalidate
  • Pragma "no-cache"
  • Expires 0

Besides the "standard" set above, I found this article, recommending to combine "no-cache" and "no-store" with "private". As far as I understand the specification it should be sufficient to set "no-cache" and "no-store" if you want to forbid caching at all.

So my question: Are there any reasons to add the "private" header to our set? And if so, will there be a conflict between the headers?

P.S.: I also checked the following two discussions, which did not provide a definite answer.

1

I understand the contradiction (if we may call it so) you highlighted. So I read both (some parts of the specification related to the private option) and the article.

I rather searched about the original article where the bug was first mentioned. In that article, it is stated:

It was reported that multiple meta.wikimedia.org users received the same session ID. These users could act as the user who happened to be logged in according to the session value.

So you can conclude there is nothing wrong with the specification, and you need to add the private option in Cache-control only when there is a session.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.