What is the risk of having HTTP header "Cache-Control: public"?

nonopolarity picture nonopolarity · Jul 27, 2010 · Viewed 39.2k times · Source

The Cache-Control HTTP/1.1 header can specify max-age as well as whether the cache content can be public or private, indicating whether intermediate cache can cache the content.

For example, Ruby on Rails's expires_in() defaults to using Cache-Control: private

What is the risk of making it public? If it is public, which extra places can cache the content -- would it be a proxy server, for example?

What if the website is like Amazon.com, but the user is anonymous, then probably there is not much privacy issue? What if the user is logged in, could there be privacy issue, because the data passes through places and the data is visible. If that location wants to be "bad", it really doesn't need to care about the Cache-Control: private anyway.

What if it is a website where user can be logged in, but the website only search for health products like fish oil and vitamins, and so forth. In that case, there is even less privacy involved because it is unlike Amazon.com where there are a lot more variety of products such as books for which a user can really care more about privacy issue.

Having said that, what is the additional advantage of have Cache-Control: public?

Answer

Mike picture Mike · Jul 27, 2010

The problem with Cache-Control: Public is that the response may be cached and displayed to a different user. This is a problem if you have an authenticated application that is displaying private data. In general, you should only use public for static pages, or pages that return the same data no matter what user is making the request.