Cache-Control: public / private or none in combination with HTTPS (HTTP sucure)?

If you have for exampe an image with max-age=31536000, when using HTTPS what is the best to do:

Cache-Control: public, max-age=31536000

Open in new window

Cache-Control: private, max-age=31536000

Open in new window

Cache-Control: max-age=31536000

Open in new window

Which one and why?

I also did some own research, but I'm not sure yet what the answer has to be. I think this is true:

By default web browsers should cache content over HTTPS the same as over HTTP, unless explicitly told otherwise via the HTTP Headers received.

This is about the cache of the browser. For shared caches I think this is true:

If the request is authenticated or secure (i.e., HTTPS), it won’t be cached by shared caches.

Google is saying here, see:

If the response is marked as "public", then it can be cached, even if it has HTTP authentication associated with it, and even when the response status code isn't normally cacheable. Most of the time, "public" isn't necessary, because explicit caching information (like "max-age") indicates that the response is cacheable anyway.

That's what Google is saying, but I also checked what they are doing. See:

cache-control:private, max-age=31536000

Open in new window

cache-control:public, max-age=31536000

Open in new window

So why there are using "public" in the latter case? That's not what they were saying before (see quote above). What's the difference between those 2 urls? Why the first "private" and the second "public"?

Some people on the internet are saying this:

The slight caveat is that Firefox will only cache HTTPS resources in memory by default. If you want persistent caching to disk you’ll need to add the Cache-Control: Public response header.

I tested this with for example: The source contains:

cache-control:max-age=604800, must-revalidate

Open in new window

This will store / cache the resource in disk, so from what I can see it's not true (anymore)?

And what will happen if an intermediate cache / shared cache will store a HTTPS response, does it makes sense? Is it correct that with "public" shared caches are also storing HTTPS responses, so actually that's what "public" is doing in combination with HTTPS?

With HTTPS, the response is encrypted and only the client can interpret it. So for other clients it makes no sense to store a specific HTTPS response. Is there a situation where it makes sense for the client who can interpret the HTTPS reponse? Only when a client has no own "private cache" ... then maybe it makes sense? Maybe in a case like that an intermediate cache does not have to make a request to the server, but he can serve the HTTPS response directly from the intermediate cache. If the client has his own "private cache", then the source will come anyway from his own cache, so then "public" has no extra meaning. So I'm wondering if there are anyway situations (and which?) where "public" in combination with HTTPS makes sense?
Maarten BruinsAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
browser caching

From novice to tech pro — start learning today.