

Cripple the Google CDN’s caching with a single character - Encosia
http://encosia.com/2011/01/19/cripple-the-google-cdns-caching-with-a-single-character/

======
marketer
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>

~~~
JoachimSchipper
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
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
I agree with you on all points - I was just pointing out that the article did
have _some_ point.

------
tzs

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

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

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

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

