7 ms·

Microsoft's Ajax CDN tumbles worldwide

37 points by fabm 14y ago

edhooper 14y ago
It looks like the CDN still works from Australia but is down almost everywhere else
dos1 14y ago
More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc. But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Everything else might be up and working great, but how well will the UI function if the user can't pull in jQuery? I just don't see any value in taking a dependency on these third parties for hosting JS libs and the like.
- crescentfresh 14y ago
  CDN, with local fallback: <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.x.x.min.js" type="text/javascript"></script> <script type="text/javascript"> window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E')) </script>
  - dos1 14y ago
    Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request. Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.
    - crescentfresh 14y ago
      > bundle them with your other scripts and save a request There's huge merit in that IMO for single-page type applications that have many lib dependencies. For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.
      - dos1 14y ago
        I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.
  - macca321 14y ago
    This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.
    - crescentfresh 14y ago
      Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers. However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before </body>), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.
    - k3n 14y ago
      You could probably wire something up in JS to handle it with reduced timeouts, e.g. an AJAX call that automatically fails after 50-100ms and proceeds to load the local version.
      - jQueryIsAwesome 14y ago
        A simpler solution would be to reload the page passing a parameter that you want to use other CDN; something like this: https://gist.github.com/4444636 https://gist.github.com/4444636
        weego 14y ago
        You've now got people wondering why their page just reloaded after half a second and a slug of unnecessary javascript in your page all for the sake of simplicity. A simple solution would be to just link to a self-hosted version of the lib.
        jQueryIsAwesome 14y ago
        False; because (if the script is inside the head of the page) the loading of Javascript is synchronous so the user will not notice any refresh at all.
  - jQueryIsAwesome 14y ago
    Don't use unescape, is ugly and is not required if you break the close tag of "script". this.jQuery||document.write('<script src="js/jquery-1.8.3.min.js"></sc'+'ript>')
    - crescentfresh 14y ago
      Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.
      - jQueryIsAwesome 14y ago
        Well; I also think this is going offtopic but I have to mention "unescape" is not a JS standard but it is available in most JS engines; in the other hand literal Unicode codes in strings are part of the ES specification.
  - kyrra 14y ago
    If you do overall page loading times, I wonder what sort of averages you will see comparing this to hosting it locally for all requests. When hosted locally it would result in 1 less DNS lookup, as well it could reuse an open HTTP connection to fetch the resource.
    - crescentfresh 14y ago
      Correct on both counts. One con of hosting multiple dependencies locally could be that parallelization of downloads is reduced. There's always a flipside and each situation warrants analysis! So many of these discussion points are discussed at https://developers.google.com/speed/docs/best-practices/rtt https://developers.google.com/speed/docs/best-practices/rtt
    - deelowe 14y ago
      I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.
- k3n 14y ago
  I think the idea is that hosts like Google (and ostensibly, Mircosoft) are going to have availability that far exceeds your run-of-the-mill website. Those big hosts generally are going to provide five 9's (or more) availability, whereas %your_random_site% is probably going to be on the order of three to four 9's, at best. So more often than not, the point of failure is going to be your website...not the CDN. If you have the infrastructure ($$$) to support your own web services on the order of 99.999%+, then by all means host it yourself, otherwise you're most likely never going to have a problem with it (especially if you include a fallback method).
  - dos1 14y ago
    I agree completely that your average website will have less uptime than the CDN. The problem isn't that the CDNs are less reliable, it's that it's VERY unlikely that your site will experience downtime at the same time as the CDN. This means your site reliability is the combination of the downtime of the CDN as well as your own.
    - k3n 14y ago
      Yeah, but if you gracefully handle those failures with local fallbacks, then the CDN's downtime is a moot point.
      - dos1 14y ago
        See the rest of the comments in this thread about why the fallback can be painfully slow if the CDN is down. I saw your previous comment about making an ajax request with an adjusted timeout, but this is not ideal for making cross domain script requests for a number of reasons. For one, CORS needs to be enabled. Another is that you now have to create a script tag and take the responseText and jam it in there. This is going to be slower than just creating a script tag and setting the src attr. If you are going to have a fallback, and that fallback may take seconds to activate if the CDN is down, why not just make the fallback your primary?
        14y ago
- kamjam 14y ago
  This was what I was going to suggest also... but... Whatever happened to using progressive enhancement techniques which meant the site would continue to work, albeit with basic functionality, for users even without JavaScript? I understand for some sites this is not possible, but for a lot of sites it would be perfectly acceptable...
- FredFredrickson 14y ago
  This is exactly my thought on the matter. It's cool that larger sites will host these scripts for you, but why should I make my site dependent on another just for a negligible improvement in speed / caching efficiency? My feeling is that if you're going to make your site's uptime dependent on another, at least make it for something worthwhile that you can't host yourself, either because it's too demanding or too proprietary.
  - k3n 14y ago
    > My feeling is that if you're going to make your site's uptime dependent on another That's a terrible idea, and of course you shouldn't do that. You provide a fallback for the CDN...
- ChuckMcM 14y ago
  "More generally, I have never understood why people use these third party CDNs for important sites." Perhaps its not a core-competency of the company? When you're a small company you only get a few employees to work with maybe none, so you find ways to get the stuff you don't know how to do, done. Whether its contract work for design, or outsourcing operations to the cloud.
aswerty 14y ago
Well I've added CDN failure contingency to my todo list for the site I'm currently running. The lack of communication from Microsoft is annoying, even a tweet acknowledging the issue would be something.
dotBen 14y ago
If anyone still needs convincing these CDN'd JS lib are a bad design pattern, check out this presentation from 2012's Black Hat (and also DEFCON) on MITM attacks on them that persist after the user has been exposed (due to indefinite caching of poisoned JS files). http://media.blackhat.com/bh-us-12/Briefings/Alonso/BH_US_12_Alonso_Owning_Bad_Guys_WP.pdf http://media.blackhat.com/bh-us-12/Briefings/Alonso/BH_US_12..., or https://www.youtube.com/watch?v=ZCNZJ_7f0Hk https://www.youtube.com/watch?v=ZCNZJ_7f0Hk (quite entertaining presentation) the tl:dr is users browse a short time via an anonymous proxy (c'mon, many do), the proxy MITM's these CDN's JS lib requests and serves up poisoned versions that work but also check a mothership server to load in further poisoned + persistently cached JS files for popular websites (banking, facebook, etc). User then ends their proxy session but future visits (even direct, not via proxy) to sites loads in the now cached poisoned JS libs. Phishing, credential theft, clipboard theft, etc is all now possible
- kamjam 14y ago
  How often does your average user browse via an anonymous proxy? I doubt most would even know what the hell you are talking about. I can understand for your more clued up or power user, but you give the average user too much credit.
  - JonnieCache 14y ago
    Every time they use a public wifi hotspot. Any time you use a network you don't control and where you have no reason to trust the admin, you may as well be using a proxy. The requirement to trust the admin isn't about the admin MITMing you, but rather trusting their competency in preventing other users MITMing you. Of course the admin could be bad as well.
    - k3n 14y ago
      Yay for never using public wifi hotspots, now if I could only impress that upon the millions of Americans who do so everyday...
      - 14y ago
Benferhat 14y ago
This is why I use yepnope [0]. "yepnope.js has the capability to do resource fallbacks and still download dependent scripts in parallel with the first." [0] http://yepnopejs.com/ http://yepnopejs.com/

37 points by fabm 14y ago

It looks like the CDN still works from Australia but is down almost everywhere else

dos1 14y ago

More generally, I have never understood why people use these third party CDNs for important sites. Don't get me wrong, I understand the bullet points that the Microsoft's and Google's trot out: User more likely to have it cached, more simultaneously open connections since it's a different domain, perhaps less latency etc. But the simple fact of the matter is if the CDN goes down, your site essentially goes down. Everything else might be up and working great, but how well will the UI function if the user can't pull in jQuery? I just don't see any value in taking a dependency on these third parties for hosting JS libs and the like.

crescentfresh 14y ago
CDN, with local fallback: <script src="//ajax.aspnetcdn.com/ajax/jQuery/jquery-1.x.x.min.js" type="text/javascript"></script> <script type="text/javascript"> window.jQuery || document.write(unescape('%3Cscript src="/scripts/jquery-1.x.x.min.js"%3E%3C/script%3E')) </script>
- dos1 14y ago
  Yeah, I know - but why bother? Just host the libs yourself and be done with it. Plus that way you can bundle them with your other scripts and save a request. Edit: To clarify - the reason I don't like the above solution is because if the CDN is slow to respond for some reason, you've just wasted a bunch of your user's time before loading your self hosted version.
  - crescentfresh 14y ago
    > bundle them with your other scripts and save a request There's huge merit in that IMO for single-page type applications that have many lib dependencies. For content-based pages (dunno what to call them, whatever the opposite of single page apps are) the benefits stated by Google/others are more apparent with the CDN with local fallback approach.
    - dos1 14y ago
      I figure most content sites that are including jQuery are likely including some other third party libs. In the case of more than one external lib I think bundling makes sense and has a positive impact.
- macca321 14y ago
  This is what we had, but it wasn't responding quickly enough, so the site was hanging despite the fallback.
  - crescentfresh 14y ago
    Yes I've found that too. Our single-page-style apps would do better to bundle all our dependencies together into a single request to our own servers. However say for content-based sites, the theoretical ideal is that the content should be delivered and usable without the inclusion of fooLib.js (which folks say should even be included as late as just before </body>), so a delay from a CDN would not necessarily cause any apparent "hang". Again this is the ideal and admittedly I've never got it right.
  - k3n 14y ago
    You could probably wire something up in JS to handle it with reduced timeouts, e.g. an AJAX call that automatically fails after 50-100ms and proceeds to load the local version.
    - jQueryIsAwesome 14y ago
      A simpler solution would be to reload the page passing a parameter that you want to use other CDN; something like this: https://gist.github.com/4444636 https://gist.github.com/4444636
      - weego 14y ago
        You've now got people wondering why their page just reloaded after half a second and a slug of unnecessary javascript in your page all for the sake of simplicity. A simple solution would be to just link to a self-hosted version of the lib.
        jQueryIsAwesome 14y ago
        False; because (if the script is inside the head of the page) the loading of Javascript is synchronous so the user will not notice any refresh at all.
- jQueryIsAwesome 14y ago
  Don't use unescape, is ugly and is not required if you break the close tag of "script". this.jQuery||document.write('<script src="js/jquery-1.8.3.min.js"></sc'+'ript>')
  - crescentfresh 14y ago
    Yes, also document.write('\x3Cscript>\x3C/script>'). But these are beside the point.
    - jQueryIsAwesome 14y ago
      Well; I also think this is going offtopic but I have to mention "unescape" is not a JS standard but it is available in most JS engines; in the other hand literal Unicode codes in strings are part of the ES specification.
- kyrra 14y ago
  If you do overall page loading times, I wonder what sort of averages you will see comparing this to hosting it locally for all requests. When hosted locally it would result in 1 less DNS lookup, as well it could reuse an open HTTP connection to fetch the resource.
  - crescentfresh 14y ago
    Correct on both counts. One con of hosting multiple dependencies locally could be that parallelization of downloads is reduced. There's always a flipside and each situation warrants analysis! So many of these discussion points are discussed at https://developers.google.com/speed/docs/best-practices/rtt https://developers.google.com/speed/docs/best-practices/rtt
  - deelowe 14y ago
    I think for popular CDNs hosting popular libraries(google's jquery for example), the browser would use the local cache. So, I imagine there's a benefit to using a big CDN for those cases.
k3n 14y ago
I think the idea is that hosts like Google (and ostensibly, Mircosoft) are going to have availability that far exceeds your run-of-the-mill website. Those big hosts generally are going to provide five 9's (or more) availability, whereas %your_random_site% is probably going to be on the order of three to four 9's, at best. So more often than not, the point of failure is going to be your website...not the CDN. If you have the infrastructure ($$$) to support your own web services on the order of 99.999%+, then by all means host it yourself, otherwise you're most likely never going to have a problem with it (especially if you include a fallback method).
- dos1 14y ago
  I agree completely that your average website will have less uptime than the CDN. The problem isn't that the CDNs are less reliable, it's that it's VERY unlikely that your site will experience downtime at the same time as the CDN. This means your site reliability is the combination of the downtime of the CDN as well as your own.
  - k3n 14y ago
    Yeah, but if you gracefully handle those failures with local fallbacks, then the CDN's downtime is a moot point.
    - dos1 14y ago
      See the rest of the comments in this thread about why the fallback can be painfully slow if the CDN is down. I saw your previous comment about making an ajax request with an adjusted timeout, but this is not ideal for making cross domain script requests for a number of reasons. For one, CORS needs to be enabled. Another is that you now have to create a script tag and take the responseText and jam it in there. This is going to be slower than just creating a script tag and setting the src attr. If you are going to have a fallback, and that fallback may take seconds to activate if the CDN is down, why not just make the fallback your primary?
      - 14y ago
kamjam 14y ago
This was what I was going to suggest also... but... Whatever happened to using progressive enhancement techniques which meant the site would continue to work, albeit with basic functionality, for users even without JavaScript? I understand for some sites this is not possible, but for a lot of sites it would be perfectly acceptable...
FredFredrickson 14y ago
This is exactly my thought on the matter. It's cool that larger sites will host these scripts for you, but why should I make my site dependent on another just for a negligible improvement in speed / caching efficiency? My feeling is that if you're going to make your site's uptime dependent on another, at least make it for something worthwhile that you can't host yourself, either because it's too demanding or too proprietary.
- k3n 14y ago
  > My feeling is that if you're going to make your site's uptime dependent on another That's a terrible idea, and of course you shouldn't do that. You provide a fallback for the CDN...
ChuckMcM 14y ago
"More generally, I have never understood why people use these third party CDNs for important sites." Perhaps its not a core-competency of the company? When you're a small company you only get a few employees to work with maybe none, so you find ways to get the stuff you don't know how to do, done. Whether its contract work for design, or outsourcing operations to the cloud.

aswerty 14y ago

Well I've added CDN failure contingency to my todo list for the site I'm currently running. The lack of communication from Microsoft is annoying, even a tweet acknowledging the issue would be something.

dotBen 14y ago

If anyone still needs convincing these CDN'd JS lib are a bad design pattern, check out this presentation from 2012's Black Hat (and also DEFCON) on MITM attacks on them that persist after the user has been exposed (due to indefinite caching of poisoned JS files). http://media.blackhat.com/bh-us-12/Briefings/Alonso/BH_US_12_Alonso_Owning_Bad_Guys_WP.pdf http://media.blackhat.com/bh-us-12/Briefings/Alonso/BH_US_12..., or https://www.youtube.com/watch?v=ZCNZJ_7f0Hk https://www.youtube.com/watch?v=ZCNZJ_7f0Hk (quite entertaining presentation) the tl:dr is users browse a short time via an anonymous proxy (c'mon, many do), the proxy MITM's these CDN's JS lib requests and serves up poisoned versions that work but also check a mothership server to load in further poisoned + persistently cached JS files for popular websites (banking, facebook, etc). User then ends their proxy session but future visits (even direct, not via proxy) to sites loads in the now cached poisoned JS libs. Phishing, credential theft, clipboard theft, etc is all now possible

kamjam 14y ago
How often does your average user browse via an anonymous proxy? I doubt most would even know what the hell you are talking about. I can understand for your more clued up or power user, but you give the average user too much credit.
- JonnieCache 14y ago
  Every time they use a public wifi hotspot. Any time you use a network you don't control and where you have no reason to trust the admin, you may as well be using a proxy. The requirement to trust the admin isn't about the admin MITMing you, but rather trusting their competency in preventing other users MITMing you. Of course the admin could be bad as well.
  - k3n 14y ago
    Yay for never using public wifi hotspots, now if I could only impress that upon the millions of Americans who do so everyday...
    - 14y ago

Benferhat 14y ago

This is why I use yepnope [0]. "yepnope.js has the capability to do resource fallbacks and still download dependent scripts in parallel with the first." [0] http://yepnopejs.com/ http://yepnopejs.com/