Cripple the Google CDN’s caching with a single character

http://encosia.com/2011/01/19/cripple-the-google-cdns-caching-with-a-single-character/

by Encosia • 16 years ago

30 17 16 years ago

marketer2• 16 years ago

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

JoachimSchipper2• 16 years ago

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.)

nolok• 16 years 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.

Encosia5• 16 years 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.

marketer2• 16 years ago

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.

rmc• 16 years ago

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.

jmillikin• 16 years ago

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.

eli• 16 years ago

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.

Encosia5• 16 years ago

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.

CWIZO• 16 years ago

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...

Encosia5• 16 years ago

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>

Sephr• 16 years ago

> 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.

tzs• 16 years ago

    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.

wladimir• 16 years ago

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...

Cripple the Google CDN’s caching with a single character

Related Stories