Private vs Public in Cache-Control

Question

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?

Solution

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.

Comments

[Jon Hanna]

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.

[salgiza]

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).

[Jon Hanna]

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.

[Pacerier]

So if we don't specify anything, is the default behavior "public" or "private"?

[Azeez]

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.

[Bell]

@MarkSowul: that is really old. Fixed ~2010: bugzilla.mozilla.org/show_bug.cgi?id=531801

[Mark Sowul]

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.

[mfaani]

@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 httpS. right?

[Jon Hanna]

@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.

[mfaani]

@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?!

[Jon Hanna]

@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.

[mfaani]

@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...

[Jon Hanna]

@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.

[Oleksii Kyslytsyn]

There are actually three states for cache-control: private, public and unset.

[Rok Kralj]

what proxies? We are using HTTPS these days.