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.

Safari for Windows

Yes, that's right. It has finally happened. Safari for Windows is now available as a free download.

There are still some questions unanswered - my number one question is if it uses the same rendering engine as the Mac version. I hope it does.

On a side note, I wonder what will happen to Swift.