Dynamically loading Javascript or CSS resources

The separation between style and content which comes from using CSS and HTML together is great.  It really keeps your content clean, and allows you to alter the ‘look’ without cluttering the information you’re trying to present.

Adding a little javascript can be great too, all you need is a SCRIPT tag, and in comes your code!
Continue reading

Simple jQuery Nested Accordians

I am fairly new to Javascript, and while I spent a fair amount of time trying to avoid frameworks and libraries (after all, you best know the language before using some of these clever tricks!) I have come to realize that using jQuery is quite honestly a whole lot simpler than not using it!
Continue reading

No REST for Internet Explorer

The vast majority of browsers support the XMLHttpRequest object in their javascript code.  There are actually two versions of this, version 1 and version 2 excitingly enough.  Version 2 has a few more options, but essentially they both do the same thing.

Any good REST API requires the use of four HTTP methods (or REST Verbs), GET, POST, PUT and DELETE.  They also allow you to say what format you would like your response to be returned as (XML and JSON seem to be the most common types)
Continue reading

Configure Apache to accept Cross-Site XMLHttpRequests on Debian

By default it’s not possible to request a URL from a domain other than that which the requesting page came from.  This presents a bit of a problem if you’re trying to get data from a web service API.

The reason behind this is not immediately obvious.  It’s not that the browser will refuse to access an external domain, it’s actually that the domain in question won’t explicitly tell the browser that it will accept the request.

What actually happens is this:

  1. Page Load: The browser loads the page.  At some point an XMLHttpRequest object is created, properties are set, and the call is made
  2. Preflight: The browser issues an OPTIONS http request to the URL passed in to the XMLHttpRequest object.  In the header of this request, it sets the Origin to that of the domain where the page was loaded from.
  3. Authorisation: The server responds with (most likely) either a 403 (Not Allowed) or a 200 (OK) code, but with otherwise standard headers
  4. Failure: The XMLHttpRequest object cancels the load, moves to readyState 4, with a status of 0

So the browser did attempt to access the URL, but the server didn’t say it would accept a Cross-Site request!

What we really need is get the server to tell the browser explicitly that it will accept requests from an origin other than itself.  To do this, we need to do just two things:

  1. Enable the Apache Headers module
    • a2enmod headers
    • service apache restart
  2. In our Apache config for the site, under the <Directory> section, add
    • Headers set Access-Control-Allow-Origin “*”
    • Header add Access-Control-Allow-Headers “origin, content-type”
    • Header always set Access-Control-Allow-Methods “POST, GET, PUT, DELETE, OPTIONS”

When we try again now, we should see the response to the OPTIONS request contains the headers we asked it to add.

You’ll notice we’re explicitly setting the following things:

  • We will allow requests from ANY (*) origin
  • We will allow 5 different HTTP methods (POST, GET, PUT, DELETE and of course, OPTIONS)
  • We will allow Cross-Site requests to include Origin, Content-Type and headers.

Now our XMLHttpRequest object is happy that the server will accept a request from us, so there will then be a second request, which is the one we actually wanted to get our data.

The difficulty most people have is that the initial OPTIONS request isn’t visible to the server side code unless these directives are present, so you end up going in circles blaming the Javascript, then the XMLHttpRequest object, then the server side code and so on.

The same directives can be set in the .htaccess file if you don;t have direct access to your servers Apache conf files.