3 ms·

From the article: "browsers do not cache files to disk if they’ve been retrieved via SSL" I don't think that's correct at all. Perhaps browsers have more secur

From the article: "browsers do not cache files to disk if they’ve been retrieved via SSL" I don't think that's correct at all. Perhaps browsers have more secure defaults with SSL, but if you're explicit and specify Cache-Control headers, it'll be cached. The jquery version specified on Google CDN's have Cache-Control public, so it'll be cached on disk. Just put up a blog post about this: http://news.ycombinator.com/item?id=2120773 http://news.ycombinator.com/item?id=2120773

JoachimSchipper 16y ago
I think the author was pointing out that, if you put https://.../jquery.js https://.../jquery.js in your page and a visitor comes from a site using http://.../jquery.js http://.../jquery.js, he'll have to re-download the file. (The HTTPS resource is cached, but the browser doesn't use the in-cache HTTP resource.)
- nolok 16y ago
  Which is the correct way to do it. If the URI change, then the content can not be assumed to be identical. You can set up a server to serve two totally different websites on the same domain name, one on http and the other on https. If both those site have a javascript file of the same name at the same path, I certainly do not want my browser to confuse them. On top of that, that's not "crippling google's CDN caching" at all, that article is over exaggerating.
  - JoachimSchipper 16y ago
    I agree with you on all points - I was just pointing out that the article did have some point.
Encosia 16y ago
You may be correct about that. The last time I did in-depth testing, browsers were raft with inconsistencies when it came HTTPS caching (regardless of whether you sent the correct headers). Firefox wasn't even caching HTTPS content in memory at one point. Thorough analysis of more current browser versions would be interesting. You've glossed over the actual point of the post though. Even if every version of every browser did respect the cache-control header for SSL content, over-referencing the SSL version of the script is still fragmenting your local cache unnecessarily. With many thousand sites already using the regular HTTP references to the Google CDN, sites that use the HTTPS reference on HTTP pages are missing out on the cross-site caching benefit, which is probably the biggest advantage of using a shared CDN to begin with. I've been seeing more and more people using the fixed HTTPS reference on simple sites like WordPress blogs, thinking it's more secure or that it allows them the flexibility to offer their site through both HTTP and HTTPS. In reality, that's just harming their site's performance for most visitors, whereas the protocol-less reference gives them the best of both worlds. Hence the post.
- marketer 16y ago
  It seems Google is deprecating the http resource, though. If you visit http://code.google.com/apis/libraries/devguide.html#jquery http://code.google.com/apis/libraries/devguide.html#jquery, all paths are listed as HTTPS. This seems like a good solution -- just encourage everyone to use HTTPS to avoid the cache fragmentation.
  - Encosia 16y ago
    It has taken over two years to get to the point we're at now in terms of a critical mass of sites linking to the Google CDN via the HTTP references. I'd have a hard time recommending people begin switching to the SSL reference now (sacrificing that cross-site caching benefit that has accumulated) unless they're actually serving encrypted pages and need to solve the mixed content issue.

JoachimSchipper 16y ago

I think the author was pointing out that, if you put https://.../jquery.js https://.../jquery.js in your page and a visitor comes from a site using http://.../jquery.js http://.../jquery.js, he'll have to re-download the file. (The HTTPS resource is cached, but the browser doesn't use the in-cache HTTP resource.)

nolok 16y ago
Which is the correct way to do it. If the URI change, then the content can not be assumed to be identical. You can set up a server to serve two totally different websites on the same domain name, one on http and the other on https. If both those site have a javascript file of the same name at the same path, I certainly do not want my browser to confuse them. On top of that, that's not "crippling google's CDN caching" at all, that article is over exaggerating.
- JoachimSchipper 16y ago
  I agree with you on all points - I was just pointing out that the article did have some point.

Encosia 16y ago

You may be correct about that. The last time I did in-depth testing, browsers were raft with inconsistencies when it came HTTPS caching (regardless of whether you sent the correct headers). Firefox wasn't even caching HTTPS content in memory at one point. Thorough analysis of more current browser versions would be interesting. You've glossed over the actual point of the post though. Even if every version of every browser did respect the cache-control header for SSL content, over-referencing the SSL version of the script is still fragmenting your local cache unnecessarily. With many thousand sites already using the regular HTTP references to the Google CDN, sites that use the HTTPS reference on HTTP pages are missing out on the cross-site caching benefit, which is probably the biggest advantage of using a shared CDN to begin with. I've been seeing more and more people using the fixed HTTPS reference on simple sites like WordPress blogs, thinking it's more secure or that it allows them the flexibility to offer their site through both HTTP and HTTPS. In reality, that's just harming their site's performance for most visitors, whereas the protocol-less reference gives them the best of both worlds. Hence the post.

marketer 16y ago
It seems Google is deprecating the http resource, though. If you visit http://code.google.com/apis/libraries/devguide.html#jquery http://code.google.com/apis/libraries/devguide.html#jquery, all paths are listed as HTTPS. This seems like a good solution -- just encourage everyone to use HTTPS to avoid the cache fragmentation.
- Encosia 16y ago
  It has taken over two years to get to the point we're at now in terms of a critical mass of sites linking to the Google CDN via the HTTP references. I'd have a hard time recommending people begin switching to the SSL reference now (sacrificing that cross-site caching benefit that has accumulated) unless they're actually serving encrypted pages and need to solve the mixed content issue.