November 22, 2014
Reading Time: 2 minutes

So I finally got time to jump back onto my personal project for my next startup, and must say I ran into quite the issue. Because my API is setup and deployed on my server, I’m required (because of AJAX) to do OPTIONS requests, which upon success, will follow up with the actual request on success.

But something went wrong.

I thought, maybe I changed a configuration file or there’s some bug. Looked in the application logs, as well as the apache logs. Nothing.

I googled every possible permutation that came to my mind for what mind show me some possible idea as to what in the world was happening. Mind you, all other requests (GET, POST, PUT, DELETE) were all working correctly. But I needed OPTIONS to work for my application. I reviewed all the apache and program configurations.

In total, I spent probably 3-4 hours on this. Did curl requests to only get an error (52) empty response. It finally dawned on me that something had to be interfering with my connection. I wasn’t even getting a response from the server, but since the other responses worked, I knew the server was working.

I finally stumbled upon this information on Ben Nadel’s site:

During the week I installed Cisco AnyConnect so that I could get my company vpn working on my macbook without having to use their laptop, which just slows me down from sometimes doing what I need to do. Uninstalling Cisco AnyConnect completely fixed my issues instantly!!!

I’d never felt so relieved in my life! After losing a better portion of the day, I finally was back in the position to start making headway on my application.

Hope this can help anyone who comes across it.

I’m also adding my list of googled search terms in the event anyone else has the same issue, but hasn’t found the right fix yet:

apache header set access-control-allow-origin “*”

apache Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at

chrome OPTIONS (failed) net::ERR_EMPTY_RESPONSE

cors not working in apache

apache no response from OPTIONS

apache not adding allow-headers

htaccess access control allow origin not working

apache options request failed

apache options request empty response

OPTIONS curl Empty reply from server


AngularJS Cannot read property ‘1’ of null error.

August 16, 2014
Reading Time: 1 minute

tl;dr Check your views for any empty directive tags, such as ng-controller=””.

When you’ve been using AngularJS long enough, you quickly realize that some of the error messages can be pretty cryptic. This one is no substitute:

Cannot read property '1' of null

Some of these errors will send you into an instant mental panic, thinking…!

I’m not sure of all of the cases that this error will appear, but for me it was because I left an ng-controller=”” empty in the html view. So if you get this error begin looking for any empty directives tags in your view(s).

Circular References in AngularJS

July 1, 2014
Reading Time: 1 minute

I just encountered this for the first time yesterday, and was absolutely perplexed by it. So much so, that I completely reversed my commit to walk through it to try and figure it out.

Even though I’ve now found that including one of my services in another service is creating this problem, I did stumble upon this resource from Misko Hevery. Very well done indeed for helping you figure this problem out:

Creating Your Own Custom Directive Library – In Isolation

May 20, 2014
Reading Time: 2 minutes

I’ve had to come up with a better strategy recently for making custom directives that didn’t involve make subtle changes in the browser, save file, refresh, go to said feature, check it. Mess with things in Chrome Dev Tools. See what it does, etc. That sucked.

So, I did what anyone with a problem does. Try and solve it. I knew that some of the custom directives I needed would require certain server api data (list of customers, customer detail, etc.), so that had to be figured out, but then I still needed an isolated way that was also very organized for making custom directives. From this, I stumbled upon one of my favorite time savers.

Custom Directive Library In Isolation

1) Open Google Chrome.
2) Go to the Chrome Developer Tools and click on Network.
3) Navigate to the page you need data from or use an extension to make the API call.
4) Locate the API call in the Network activity list.
5) Right click the call and select Copy Response.

You now have a server replica of the exact data and format that would come from the server to mess with, in the next steps. I take this and assign it to a JavaScript variable and can forget about having to always have memorized the data format coming from the server.

Next you need an online all-in-one editor. There are many out there, I happen to prefer Plunker ( because it has version control built-in, it makes it super easy to add whatever libraries and frameworks you need. You could make a default template for your project and just fork it every time you need to start a new custom directive, giving you the perfect boilerplate code to jump right into the actual coding and not start off with having to do the same boring setup routine every single time.

Before you know it, you’ll have around 10-20 custom directives for use either in a single project or multiple. Customizing a single directive for a different project is extremely simple with forking, but best of all, it saves all of your directives in a single, sharable (and hopefully organized) repository.

I’ve found that with this technique, I’ve cut my custom directive development time by 40-60% depending on where I’m creating it in the application (inside of a page, after you login and click on item ABC, to find a feature in the modal popup…. :/) and probably increasing my custom directive development enjoyment by as much, if not more.

Hopefully this tip helps you as much it has helped me.

AngularJS IE Findings

February 5, 2014
Reading Time: 2 minutes

I recently had the joys of getting an AngularJS app I had created, working with IE9, and then subsequently IE8. If you haven’t had to do this, be happy. If you don’t have to ever do this, be even more happy. Internet Explorer will break your app from working correctly, for some very simple things. I wanted to post this to save people from the hours I had to spend, to finally track down the problems.

My initial plan of attack was to go to the AngularJS IRC Channel (#angularjs on freenode), I got responses like:

The best way to support IE8, is to show an alert that says to upgrade to IE9.

If you have to support an SPA in IE8, get a new job.

Even if tongue in cheek, none of them were helpful. The AngularJS docs on IE support were helpful in at least showing me the different things that I needed to incorporate into my application to prevent IE from freaking out on the custom tags and to use everything as attributes on existing html tags, rather than having AngularJS elements.

So here’s my run down of what had to be done in order to get this app to run in both IE9 and IE8:

  • No HTML5 tags (will break IE8)
  • Be sure there are no console.log statements ANYWHERE. (will break IE9)
  • Make sure your custom directives are defined as new elements in the index page header. // document.createElement(‘my-directive’);
  • I couldn’t get the AngularUI modal window to not throw an ‘unknown injector’ error in IE8, so I had to remove this functionality, and replace it with just an alert.
    • You could have something to check the version of IE and use one set of JavaScript over another however. I just didn’t have time to do this.
  • ng-include was breaking if any of the included parts had HTML5 tags.
  • Careful how you do your routes. See more on this below.

I originally was using my own modified version of John Papa’s Hot Towel Angular build combined with the AngularJS Seed build. However, the way that Hot Towel Angular does it’s routes, would break IE8, and I again didn’t have time to try and debug it further. So, I had to modify this to the way the AngularJS Seed build does the routes.

Please let me know if there are any other items that could be added to the list above. And just know, that AngularJS 1.3 will be dropping support for IE8 altogether. (Windows XP and IE8 support officially end April 2014).