Month: April 2012

CORS: HTML5 approach to crossdomain policies

Traditionally web browsers restrict loading content to the same origin server. This means that you can’t load content from another domain different than your own. There’s been several ways to solve this problem and HTML5 introduces a new one.

Current support


JS developers have used a workaround consisting in using JSONP (JSON with Padding). Since the same domain restriction don’t apply to dynamically loaded Javascript code, JSONP solves the crossdoamin issue by wrapping the JSON response in a JS function call. This approach assumes the server is ready to deliver JSONP data. JSONP is quite common and jQuery supports it natively.


This crossdomain policy behavior is well known in Flash as well and developers have been getting around this restricction (also imposed in the Flash player) with the –now famous– crossdomain.xml policy file.

All these approaches require the foreign server to implement a solution on their end (host the crossdomain file or implement JSONP).


One of html5 new features allows for a different workaround to crossdomain restrictions that doesn’t involve changing the format of the response but rather the header of it. This means that we can get away without JSONP and utilize JSON or any other format prefered by our app.


This new feature is called CORS (Cross Origin Resource Sharing) and its intended to prevent crossdomain scripting attacks while still enabling sites to load content from external servers.

It works in two simple steps:

STEP 1: HTTP Request

Besides setting who the host of our request is ( we also set who the requester is:


This Origin header is set by the browser and can’t be controlled by the user, and it’s send along with the full HTTP Request header:

GET /cors HTTP/1.1
Accept-Language: en-US
Connection: keep-alive
User-Agent: ...

STEP 2: HTTP Response

If the server accepts crossdomain requests its response will include (besides the requested content) who the response is intended for ( All the new HTML5 headers for CORS are prefixed with “Access-Control-“.

Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: FooBar
Content-Type: text/html; charset=utf-8


CORS is an HTML5 feature and, therefore, it’s not yet fully implemented across all browsers. Particularly, it’s not supported yet on Opera (desktop or mobile) and supported only partially in IE8 and 9 (using the XDomainRequest object but with some crazy restrictions).

The good news is that jQuery already implements CORS requests ( natively for all browsers that can support it. Additionally there are some plugins in development for IE8 and IE9.

You can check the full support for CORS for more details.


Leaving Opera aside and old versions of IE (6 and 7), CORS are pretty well supported and can be reliably used. If you own the infrastructure you can more easily get over the biggest hurdle which is implementing Access-Control headers on the external server (although this will become more and more common, it still isn’t).

Because CORS eliminates the need for JSONP, code can be simpliffied and different response formats can be used again: plain HTML, XML, JSON, etc.


You can read the w3c definition of CORS or the more readable tutorial at HTML5Rocks.

Introduction to version control with Git and GitHub

In the last year I’ve moved more and more towards Git and since I’ve started using Github I don’t want to go back to old SVN. Git is fast and reliable version control system, and Github is the perfect tool for version control, doing code reviews and managing feature development and hot fixes.


The first reason that made Git so attractive was managing more than one paralel paths of development at once (eg. feature development that needs to happen in paralel with the deployment of hotfixes). With SVN all work not related to the hotfix would have to wait to be committed to the server, or very careful measures would have to be taken to avoid code rollovers. The concept of branches is integral to the way Git works and makes it extremely simple to switch development paths and manage complicated deployments. Also, unlike SVN, Git is fast.


Git branches allow to really quickly archive the current state of the project, change context and start experimenting. If the experiment goes awry it’s a breeze to get back to the original state, if it’s a success it can become the new development branch. Great for big refactoring efforts, experimental features, etc.

Branches also facilitate colaboration among many developers and some successful branching models have been set up to assist big groups to cooperate successfully. We follow this model (or slight variations of it) in many of our projects.

Server-less commits

Cloning a Git repo actually clones the whole project not just the files of the current state of the app, which means that you have a perfect copy and are free of using the server repo. Git is great for offline development since developers can commit files locally, repeatedly, without a server and finally push their work to the repo once online (with the full history of commits).


Github is the perfect companion to Git. Since I have more and more adopted the cloud paradigm. One big advantage of Github is not having to physically clone a repo in order to be able to review code, check the history of a branch, review pull requests, etc. Finally Github is free for Open Source projects which makes it really attractive as a starting point for many.

Link to code

Something I really enjoy about Github is being able to link to sections of code. As simple as this might seem there never has been an easy way to do this.

Pull requests

Instead of blindly merging new code into the repository, developers can submit a pull request, a request to merge their code into the main branch (or trunk, or master) that can be reviewed, commented on and approved. Github can display the pull requests, conversations and resolutions. Pull requests are technically a Git feature, but the way Github handles them makes it pretty awesome to use.

Git Blame

Last feature that I really enjoy is blaming. Blaming allows anyone to determine the author of each line of code in a file. This is another feature that belongs to Git (also to SVN), that is greatly enhanced thanks to Github’s UI.


The Git Community Book: Freely available online and maintained by the community.

Book. This book has been built by dozens of people in the Git community, and is meant to help you learn how to use Git as quickly and easily as possible.

Pro Git: Published by Apress, the book is free online.

Here you can find the full content of the book, a blog with tips and updates about Git and the book and open source projects related to Git or referenced in the book.