Cripple the Google CDN’s caching with a single character | Hacker News Reader

Cripple the Google CDN’s caching with a single character

encosia.com

30 pointsEncosia17 comments

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

I think the author was pointing out that, if you put https://.../jquery.js in your page and a visitor comes from a site using 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.)

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.

I agree with you on all points - I was just pointing out that the article did have some point.

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.

It seems Google is deprecating the http resource, though. If you visit 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.

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.

    To ensure airtight security, pages served via
    SSL should contain no references to content served
    through unencrypted connections. The reasoning behind
    this rule is sound. After all, the browser has no way
    of knowing whether an image contains a chart with
    sensitive financial data or if a JavaScript include
    contains a JSON collection detailing the user’s medical
    history.

I don't see how what the browser doesn't know is relevant. The type of references are determined by the page author, who should know which reference sensitive material and which do not.

Following http links (especially to javascript and css) on https pages opens the door to all kinds of exploits. It undermines most of the security that https brings. The http links can easily be man-in-the-middle attacked, insering content into the protected page. This can be used to steal data, for starters...

The author recommends using protocol-less urls for content, but do they actually work in most browsers? Most js include this use js to determine the http vs https part of the url. Google analytics does this.

I used them for a short time on my site -- they work as expected in browsers, but some less-used agents (eg, iPhone feed readers) didn't know how to parse them. If you need to support every device, absolute URLs are the way to go.

They do work in every browser browser I've tested. It's worth noting that I did find a couple browsers that won't accept a protocol-less URL in the address field (iOS Safari being one), but those browsers did properly handle protocol-less script references in documents. So, it's easy to mistake those as browsers lacking support, but they actually do handle the protocol-less URLs correctly where it matters.

I ran this simple HTML page through Browser Shots to test about as wide a variety of browsers as possible, quick and easy:

  <html>
    <head>
      <title>Testing protocol-less URL</title>
    </head>
    <body>
      <p>A message should hopefully appear below me...</p>
    </body>
    <script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
    <script type="text/javascript">
      if (typeof jQuery !== 'undefined') {
        jQuery('body').append('<p>Protocol-less reference worked!</p>');
      }
    </script>
  </html>

> I did find a couple browsers that won't accept a protocol-less URL in the address field

Why would you expect them to accept that? The URIs aren't protocol-less, they have relative protocols, and there's nothing to relate the URI to.

I didn't know what to expect, which is why I was testing. All of the desktop browsers on my machine do resolve the protocol-less URL in the address field though (as HTTP).

I mentioned it because I can see how it would be easy to notice that behavior on the desktop, see the same thing fail on an iPhone, and then assume that mobile Safari doesn't support these URLs at all.

I'm wary of using them myself, but note that Google is actually using a different hostname for HTTPS versus HTTP, so this isn't an option for them.

As it turns out, Google does serve the script with SSL at https://www.google-analytics.com/ga.js if you request it. So, //www.google-analytics.com/ga.js works.

Internet Explorer will download CSS files twice if served with the relative protocol "thingy": http://www.stevesouders.com/blog/2010/02/10/5a-missing-schem...

Reply on news.ycombinator.com