HTTP, URIs, HTML, Oh My!

Tim Berners-Lee's definitions HTTP, URIs and HTML  ensured that the web uses a page-based metaphor. Until recently, this has stuck with us pretty much unchanged. Sure, we had frames, and they died a death. The page request/response cycle is baked hard into our web developer psyche, and the web browser's UI is predicated on pages and URIs.

Roll forward to today, and techniques such as AJAX challenge this. Pages are dynamically generated and changed on the client, and what you see on the page is not just represented by the URI and server state.

The result is that we've broken the back button. And we've broken bookmarks. And this is a bad thing.

AJAX and friends have broken the page metaphor, and as a consequence, have broken some of the key controls that users have over their web experience.

While technology changes daily, people don't. And people get confused then the back button on their browser doesn't work, or they suddenly can't add a favourite or a bookmark to the page that they're currently looking at.

There are some ways around it, though it's pretty rare to find them implemented. GMail, for example, seems to work around it through clever page design: whenever you visit a page which logically can have a predecessor, the app does a full page load (thus maintaining the behaviour of the back button). AJAX-y functionality is reserved for 'drilldown' operations, such as opening up all the messages in a thread.

Sadly, GMail is in the exception, despite browser back button support increasingly being built into open source toolkits.

I should point out, of course, that this is hardly a new problem. A quick Google returns plenty of articles from 2005. But the problem doesn't seem to have gone away quite yet.

The Cloaked Figure

The other great enemy of the browser back button is ASP.NET.

ASP.NET is the cloaked figure in the corner.

In case you haven't used it, ASP.NET is obsessed with POSTs. Completely. It even supplies a LinkButton control that effortlessly converts dirt simple hyperlinks into form posts. It does this because the ASP.NET model attempts to layer a stateful processing model (in the style of traditional desktop applications) on top of the stateless HTTP by sticking great lumps of state in hidden form fields. This is why ASP.NET apps can feel 'sticky' to use; your browser is uploading and downloading large chunks of state information with each and every request. And it's also why a carelessly-written ASP.NET web site will break without javascript enabled - it's used to change all those link clicks into form submits.

This tendency to use a post for everything, and the default behaviour of immediate cache expiry breaks the Back button in a new and exciting way. (Chris Shiflett has a nice explanation of why this is, and how to work around it. So good, I've pinched his picture. You can have it back if you want, Chris!)

Does this look familiar?

POST error

The text differs between browsers, but the meaning is the same - you pressed Back (or Forward, but nobody uses that) and the browser can't display the page without resending some data which has expired from the cache. Which might mean you order that La-Z-Boy twice. Trouble is, when everything's a POST, you're probably going to see this more often, because caching is hard to get right.

So what to do?

It's pretty simple.

• If you're an AJAX person, use one of the many techniques available to not break the back button.
• If you use ASP.NET, then use GETs where it makes sense. You might find the (Or don't use ASP.NET. It's horrible. You know I'm right. But that's for another day.)

  People, this isn't a new problem. And there's no need to use POST for every little link.

  Another rant over.