153

Can you please describe an example indicating difference between Public and Private Cache-Control in asp.net applications hosted in IIS.

I read in MSDN that the difference is the following:

Public: Sets Cache-Control: public to specify that the response is cacheable by clients and shared (proxy) caches.

Private: Default value. Sets Cache-Control: private to specify that the response is cacheable only on the client and not by shared (proxy server) caches.

I am not sure I have completely understood the pros and cons from each choice. An example for when to or not to use it would be great.

For example what should I do if i have two web servers hosting the same application? Is there anything to watch out if I choose Private or Public?

quietmint
  • 13,885
  • 6
  • 48
  • 73
ppolyzos
  • 6,791
  • 6
  • 31
  • 40

1 Answers1

270

The only difference is that with Private you are not allowing proxies to cache the data that travels through them. In the end, it all boils down to the data contained in the pages/files you are sending.

For example, your ISP could have an invisible proxy between you and the Internet, that is caching web pages to reduce the amount of bandwidth needed and lower costs. By using cache-control:private, you are specifying that it shouldn't cache the page (but allowing the final user to do so). If you use cache-control: public, you are saying that it's okay for everyone to cache the page, and so the proxy would keep a copy.

As a rule of thumb, if it's something everybody can access (for example, the logo in this page) cache-control: public might be better, because the more people that cache it, the less bandwidth you'll need. If it's something that is related to the connected user (for example, the HTML in this page includes my username, so it won't be useful to anyone else) cache-control: private will be better, as the proxies would be caching data that won't be requested by other users, and they might also be keeping data that you don't want to be kept in servers that you don't trust.

And, of course, everything that is not public should have a private cache. Otherwise the data might be stored in a middle proxy server, were it could be accessed by anyone with access to it.

salgiza
  • 5,832
  • 2
  • 26
  • 32
  • 42
    The only difference is that with Private you are **not** allowing proxies to cache... I'm guessing this was a typo. +1 on the answer apart from that. It's worth adding that private does not offer any degree of security, it can still be seen by agents in the middle. It just means that no "honest" agent will give it to someone else instead of a freshly generated response. – Jon Hanna Aug 16 '10 at 11:31
  • Fixed! It's funny because I re-read it a few times before posting, but I guess I knew the "not" had to be there, so my mind just added it :D. And yes, +1 to your comment, because it should be noted that, while recommended for user-related data, private won't replace true security (SSL). – salgiza Aug 16 '10 at 11:39
  • It's so easy to either write "not" when you shouldn't or omit it when you should. I know a large number of my own self-edits (in different fields) is fixing that same typo. – Jon Hanna Aug 16 '10 at 12:13
  • 18
    So if we don't specify anything, is the default behavior "public" or "private"? – Pacerier Aug 25 '13 at 06:55
  • So, the **cache-control:private** is only related to Proxy caches only. It is not related to Browser Caches. am I right? Please, edit the answer if I am wrong to help other readers. – Azeez Jun 11 '14 at 14:06
  • @MarkSowul: that is really old. Fixed ~2010: https://bugzilla.mozilla.org/show_bug.cgi?id=531801 – Bell Feb 11 '17 at 23:03
  • Good to know; looks like I was replying to a comment that was also deleted. I wish I remember more what was going on in my project that brought me here back then. – Mark Sowul Feb 12 '17 at 22:59
  • @JonHanna confused! 1. Do you mean if we set it to `private` still the proxies *can* cache it? 2. And even regardless of proxies caching it or not, can't the proxies always sniff/look into data? I'm guessing the answer is no—if it's http**S**. right? – mfaani Jul 15 '17 at 20:25
  • @Honey 1. The proxies shouldn't cache `private`, my **not** above was a suggested fix to the original version of the answer that it was since edited to include. 2. Telling proxies not to cache is purely a correctness matter, not a security one. Of course you shouldn't be letting proxies cache sensitive data, but if it's sensitive you shouldn't be depending on them playing by the rules either, so yes encryption is the way to go. – Jon Hanna Jul 15 '17 at 22:44
  • @JonHanna Got it thanks. I won't do this, but why would any proxy company care? Won't they just **always** go ahead and cache to reduce bandwidth?! – mfaani Jul 15 '17 at 22:59
  • @Honey because eventually their customers would realise the reason they got web pages saying "Welcome, Alice" when their name is Bob along with stuff just not working was their fault, and stop using them. – Jon Hanna Jul 15 '17 at 23:01
  • @JonHanna I don't understand how that could happen? I mean end client and the proxied would all have the save `max-age` so it's like the proxy would go outdated before the client... – mfaani Jul 15 '17 at 23:07
  • 1
    @Honey but there can be several clients using the same proxy. If it's okay send all clients the same response then it's okay to cache at the proxy level, otherwise it might be okay to cache at the client (there are still cases where even that's a bad idea), but not on the proxy. – Jon Hanna Jul 15 '17 at 23:12
  • There are actually three states for cache-control: private, public and unset. – Oleksii Kyslytsyn Jul 14 '19 at 07:13
  • what proxies? We are using HTTPS these days. – Rok Kralj May 29 '22 at 12:46