Monday, June 18, 2007

URI fragment identifiers and HTTP

I came across an interesting problem today with how HTTP handles URI fragment identifiers. Here's the spoiler - it does not!

Here's the long story. If you are on a page which has a URL that looks like this:
http://www.domain.com/page.html#fragment

Now, #fragment is known as the URI fragment identifier. This particular thing has got very popular lately with it's potential uses in Ajax applications, since it can be easily (mis)used to let client-side code perform many actions.

This also helps take care of some back-button problems with Ajax. For example, let's say you are on page.html. Then, you perform some client-side operation that appends #fragment to the URL. Now, let's say you navigate to page2.html and press the back button, you would land up on page.html#fragment. Then, the JavaScript on the page could read the #fragment and perform an Ajax action to restore the page to the state you had left it at.

However, I just discovered when working on this one project that the #fragment is never sent to the server as part of the request headers. The HTTP specification says nothing about handling URI fragment identifiers, and sure enough most browsers do nothing with them.

So, if you ever have to read the #fragment on a server, remember that you can't! That's just one more of the problems that we have to deal with as RIA developers.

3 comments:

jinny said...

Good One ......... Really helpful post ^:)^

Vivek said...

Hi Rakesh - I havent touched code for almost 3 years, but my gut tells me if you URLEncode the complete URL (including the fragement) - it should be possible to trap the fragment at the server side with a bit of code. Agreed doesnt solve HTTP's handling of the issue - but is still a potential way out.
Cheers!

Fraser said...

You can easily use a client side script to pass on the fragment as a regular GET or POST query to a server....

ShareThis