15

I understand that sensitive data should not be cached (ie, you dont want to cache an HTML file with all of your bank account details in it), but there are some things that HTTPS protected sites should be able to cache (Javascript, CSS, images, etc). Tomcat doesn't seem to allow developers to explicitly define a file to be cacheable once SSL/TLS has been enabled, and I understand that even if they did the user's browser only uses an in memory cache for HTTPS sessions and discards everything once the session is over. With the whole Web 2.0 thing thats going on, it seems to me that site operators would be interested in this ability to reduce loads on their sites (as well as page load time) while maintaining the "green bar" in the user's browser that gives us all a warm, fuzzy feeling inside.

UPDATE: removed bits about validating the cached files with an HMAC since it would be useless. If the attacker is exploiting some form of hash collision then it doesnt matter if the hash is calculated with a secret key or not.

Improve this question
5
  • Of course you could always run into a difficult user who runs with 0 cache.
    – this.josh
    Commented Sep 9, 2011 at 8:17
  • 1
    true, but most people leave their browser defaults alone, so I suspect he would be the exception rather than the rule
    – senecaso
    Commented Sep 9, 2011 at 8:29
  • 3
    "the user's browser only uses an in memory cache for HTTPS" - so not true.
    – symcbean
    Commented Sep 9, 2011 at 12:04
  • Ya, I figured that out after reading the link posted by Hendrik below. Apparently that was only true for older browsers.
    – senecaso
    Commented Sep 9, 2011 at 12:38
  • Also see stackoverflow.com/a/174510/632951
    – Pacerier
    Commented May 5, 2014 at 15:24

1 Answer 1

Reset to default
18

Use this header in your https response:

Cache-control: public

Or add ", public" to your existing Cache control header.

Use the Cache control: public directive to enable HTTPS caching for Firefox.

Some versions of Firefox require that the Cache control: public header to be set in order for resources sent over SSL to be cached on disk, even if the other caching headers are explicitly set. Although this header is normally used to enable caching by proxy servers (as described below), proxies cannot cache any content sent over HTTPS, so it is always safe to set this header for HTTPS resources.

Source: Google Page Speed

The posting HTTPS Performance Tuning says in the section "Tip #3: Use Persistent Caching For Static Content" that Internet Explorer can cache static resources over https connections, too.

Improve this answer
6
  • Interesting, when I searched for this I found documentation indicating that even if you set the Cache-Control that browsers would end up discarding the cached data after it was shutdown. Do you know if the cached data is then verified in any way when the user returns to the site? Having a cached secure file is no good if it has been tampered with.
    – senecaso
    Commented Sep 9, 2011 at 8:08
  • @senecaso, that why you need to explicitly define the "public" keyword. Using just the normal max-age in the cache-control-header is not sufficient.
    – Hendrik Brummermann
    Commented Sep 9, 2011 at 8:15
  • According to the link you sent, setting it to "public" is a workaround for FF, but not other browsers. Earlier in the document, it mentions "Other older browsers may require that caching headers be set before they will fetch a resource from the cache; and some may never cache any resources sent over SSL."
    – senecaso
    Commented Sep 9, 2011 at 8:17
  • And the second link has screenshots proofing that it works for IE, too. Just try it yourself.
    – Hendrik Brummermann
    Commented Sep 9, 2011 at 8:18
  • After realizing that my HMAC verification idea was useless, this is the answer I was looking for. Thanks Hendrik!
    – senecaso
    Commented Sep 9, 2011 at 10:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .