Yes, browsers do cache SSL resources, so please use Google's CDN

http://hoisie.com/post/yes_browsers_do_cache_ssl_resources__so_please_use_googles_cdn

by marketer • 16 years ago

90 35 16 years ago

brlewis• 16 years ago

The article argued against says browsers don't cache SSL resources to disk. This is not the same as saying they don't cache them at all. Can someone test and report back the actual behavior?

EDIT: I see from an HN comment by the author that he did mean on disk.

briansmith4• 16 years ago

Firefox 3.x caches (to disk) HTTPS responses with Cache-Control: public. Firefox 4 caches HTTPS responses basically the same way it caches non-TLS HTTP responses. Apparently, IE and Chrome are also doing this more aggressive caching. (I work in Mozilla's Platform/Networking team.)

sdizdar• 16 years ago

Question: The article says that if a resource is accessed as 'http:' and then as 'https:', then the second access will not hit the cache. Is that true? Thanks.

acqq4• 16 years ago

> Firefox 4 caches HTTPS responses basically the same way it caches non-TLS HTTP responses.

Can you please explain this sentence? I hope that doesn't mean "we now treat https just like http." Thank you.

dspillett2• 16 years ago

It would be interesting to see a comparison of how common and soon-to-be-common browsers [FF3/3.5/4, IE6/7/8/9, Chrom(e|ium), common mobile browsers, ...] deal with HTTPS content by default and in response to relevant headers. No persistence, short-term persistence (not re-requesting objects currently in use elsewhere in the current document and/or other open windows/frames), up-to-session-long persistence (RAM cache), or long-tern persistence (disk cache).

I suspect there will be quite a range of behaviours, especially if you consider IE6 (which unfortunately I have to, as do many others) so a bit more consideration is needed before jumping to change expectations of static content access speeds.

Another bit of my research to add to the list of things that'll get looked into when I have some free time (i.e. when hell freezes over)...

drivebyacct2• 16 years ago

... um, why is marketer's comment here dead?

khafra• 16 years ago

My guess is the multiple links using url shorteners tripped an anti-spam algorithm somewhere.

ezalor• 16 years ago

Yes, if by "caching" you mean and only mean "caching on RAM".

acqq4• 16 years ago

For those that don't know what CDN is here supposed to do:

http://blog.patrickmeenan.com/2010/03/google-to-offer-cdn-se...

If I understood it correctly, the idea is to refer to the web resources in html in such a way to let the clients access them with the minimal possible latency, no matter where the clients are.

grandalf• 16 years ago

does anyone know if it's possible to use the Google Picasa CDN with ssl?

dstein2• 16 years ago

Sigh, you shouldn't be relying on Google for this anyways. No company should be hosting files critical for your website except you.

gnaritas2• 16 years ago

There are good reasons to use the Google version.

A: Google is likely far more reliable than your dinky little outfit, so odds are very very high it'll be up and absurdly reliable.

B: If you use the Google version, it's probably already in your user's cache saving you nearly an 80k download for a common library and making the first hit to your site potentially much faster.

dstein2• 16 years ago

A: Google is likely far more reliable..

It's not about reliability. It's about trust. When you cross-site script yourself by giving Google access to the contents of every page on your site, you are entrusting this company with your data, and all your customer's data.

No company, including almighty, do-no-evil Google should be trusted this much.

B: If you use the Google version, it's probably already in your user's cache saving you nearly an 80k download

This might be offset slightly by your web browser having to make a separate HTTPS connection to a different "secure" host. If you are this concerned about JavaScript load times you should bundle all required javascript into a single file -- one HTTP request to one server will always beat many requests to many servers.

peterwwillis3• 16 years ago

So I have an idea. For HTTPS responses that are cached to disk, 1. do we care about the security of the files on disk? 2. if so, do we do anything to actually secure this content on disk?

If 2 is 'No', could we perhaps encrypt the content with the SSL cert (or some piece[s] of it) before written to disk? Say you have an app you want/need to benefit from caching but the cached data contains sensitive information you'd like to make it harder to get at from a long-term perspective. Take some unique bits (or lots of bits; they're kind of small) and encrypt the cached data with it, and make a hash so you can reference where this cached item came from without explicitly noting where it came from. This would let you store the data with the knowledge that if somebody recovered a hard drive with this old data it would be difficult for them to figure out where the cached data came from and how to encrypt it.

I realize i'm basically asking to use public information to encrypt private data. This can't be too difficult to 'hack' around but you'd need to know what website and certificate created the cached copy (so those entries should probably leave the 'history' as soon as the browser exits). I'm not too familiar with SSL certs in general so to add extra protection you can add something like Firefox's Master Password to the encryption scheme so it's "genuinely" encrypted without data which can be found or guessed like in the SSL cert.

Sorry if this is off-topic, just popped in my head and now i'm curious.

mcosta• 16 years ago

Web developers should declare sensitive data no-cacheable.

peterwwillis3• 16 years ago

Yes, but how many web developers are in a position to decide how their documents are cached, and of those, how many care to? If it's in the web browser I can determine how sensitive data is handled so I don't have to rely on all web developers to do the right thing.

peterwwillis3• 16 years ago

Also, this may be a completely separate issue, but shouldn't persistent cookies set over https also be encrypted on disk in some way? If a bank website was found to be setting persistent cookies over https, i'd sure want the browser to be encrypting that cookie in some way before putting it on my hard disk. Again, I don't know if browsers already support this, but I think they should.

Periodic• 16 years ago

The article mentions that the HTTPS link to the resources is now default on Google's list of AJAX resources. I remember back in the day being warned that SSL connections have an appreciable overhead and so you should avoid SSL use unnecessarily. Is this no longer true? Has the overhead of https:// become negligible?

wizard_2• 16 years ago

Yes it has become negligible. Google themselves have a nice talk about it. The major overhead is in the initial handshake. Google themselves have published how the major issues were in browser behavior (caching mostly) and not connection speed or cpu cost.

daemin• 16 years ago

Could you provide a link to that talk?

joshfraser• 16 years ago

The downside is that the secure versions take longer to download if you don't get a local cache hit. I did a speed test and loaded jQuery 20 times from Google using my local machine with an unprimed cache. For the http version, the average load time was 90ms. For the https version, the average load time was 192ms. That’s over twice as slow for the SSL version. Since you can't guarantee the cache hit, it's a trade-off that doesn't have an obvious answer.

Yes, browsers do cache SSL resources, so please use Google's CDN

Related Stories