Skip to content

Server-Side support for HTML5 History API

September 12, 2012

In traditional Single-Page Applications for the web, routing was accomplished by updating the ‘hash’ section of the URL, using the ‘hashbang’ method.

So for example, if my route was setup as '/Feature/ComponentId', the resulting URL would look something like 'http://www.example.com/#!/Feature/ComponentId'.

This was great, because all browsers support updating the ‘hash’ without causing a full-page refresh, and additionally it works without requiring any support from the server, as the server would never actually see the ‘hash’ section.

This last point is important.

In modern browsers that support the HTML5 History API, routing can update the URL itself, without causing a page refresh.

So for example, the above route would actually result in something like 'http://www.example.com/Feature/ComponentId', without any need for a ‘hash’.

However, if I were to open a new browser window and enter the last URL, this would send a GET request to the server, with the complete URL. If the server is not configured correctly, it will look for such a resource and then either not find it altogether, resulting in a 404 error or result in the wrong resource being displayed.

Server-Side support for these URLs can be accomplished using two methods, one relatively easy and one more difficult.

The first method is to use URL Rewriting on the Web Server. This means that with a simple rule-based setup, your web application never actually sees invalid URLs, as they have been rewritten to point to a different URL altogether which will return the correct response. Apache supports mod_rewrite and IIS 7 uses the Rewrite Module. There are also open source projects available, or you can manually handle the request on the server and route it to the correct location.

The second method is to actually be aware on the server if the request is for a regular request or a partial request (with Ajax, for example), and respond with content to match. If I am not mistaken, GitHub uses this method when browsing a repository’s files.

While the second method is more difficult to implement, the first method has some disadvantages. You are relying on an external web server feature or library, which in some cases are unavailable. In other words, it might be easy to have a simple Rewrite rule, but you may end up spending time getting the feature setup on the server.

Another disadvantage is performance: your page may end up making multiple requests for HTML and data just to display the requested feature.

Advertisements
Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: