Axiom: In HTTP, GET must not have side effects.

Alex Bosworth's Weblog: Google's new web accelerator breaks webapps
Univeral Resource Identifiers -- Axioms of Web architecture

I knew it for a long time - learned a hard way. But how often you see ASP pages which include statements modifying database data in visible pages - pages containing HTML, how often you see such pages being linked from other pages! It's a GET operation when you follow a link!
Moreover, one thing which I don't like in ASP.NET (and it's a common tendency for Microsoft's products for developers) is that it tends to hide everything. There is no server and client, everything is mixed together into web controls. I don't need to know if it POSTs or GETs or is just sitting on a client in JavaScript. In my experience, such attempts always fail: to program something meaningful you have to now inner details.

Hijax:

DOM Scripting: Hijax
Adactio: Journal - Progressive enhancement with Ajax

I like this idea of "progressive enhancement and graceful degradation" using a modular server-side architecture "capable of returning entire pages or portions of pages"! It's clear and doable!
Basically, you need to write a set of functions or maybe a class with a set of functions running on a server and then have one page [with server side script and no html] which handles a normal form POSTs using a set of those functions, and other pages which handle xmlhttp request post/get submissions by using an appropriate subset of the same functions. It could be even the same page which behaves differently depending on who and how calls it. A kind of Web Service :)
This page then either redirects to an appropriate HTML page, or just sends an appropriate XML or text back to AJAX caller.

Dynamic web applications and disabling browser's "Back" and "Forward" buttons.

Introduction:
I have recently read several good articles talking about problems with browser's "Back" and "Forward" buttons on AJAX, and, speaking in more general terms, any web pages with a dynamic content. Basically: when user clicks one of these buttons browser loses document's state. So, it is not possible to go back. It's perfectly described in isolani's article.

It's a long known problem with pages with frames, dynamic PHP/ASP pages using session variables, etc. People discuss various possibilities to save a state in browser's history/cache and for AJAX commands to add entries into history/cache. I believe that as this problem has only one radical solution: a web browser should allow HTML document to conditionally disable "Back" and "Forward" buttons.
Such dynamic web pages are not plain but rather web applications - speaking in isolani's terms. And an old web ideology which restricts from doing that does not apply to such pages.
Not everybody knows that Internet Explorer already allows to control these buttons in a indirect way with its onbeforeunload() event.

Again, here are several articles when people desperately try to resolve these issues:
Fixing the back button that AJAX broke
Hijax
Back button and Undo in Ajax applications
public-webapi@w3.org - Ajax Back/Forward History problem – saving document state

I sent a couple of messages in reply to this lists.w3.orgdiscussionn - not sure when and where they will appear. So, below is a copy of these messages:

***************
In reply to Karl Pongratz's message I said the following:

Karl Pongratz wrote:
> I also want to note that I wanted to propose something
> simple that solves the emerging Ajax web application web
> browser history problem, something that is strongly tight
> to the xmlhttp request object and would be easy to
> implement by user agent vendors.

Karl, I strongly believe that modifying browser's engines to save *state* in addition to URL just cannot be simple enough. I highly doubt it would be implemented any soon.

As says here, "Part of the AJAX problem is understanding whether an AJAX enhanced page is actually a web application, or is it still just a web document?"

I believe that an AJAX enhanced page should be considered a web application by itself. I also believe, that the best and really easy solution would be to conditionally disable "Back" and "Forward" buttons on an AJAX page. When I said "conditionally" I meant that in case a user clicks one of these buttons a browser should display a confirmation window asking if user really wants to *leave application*.

Yes, it would break a "pure HTML ideology", but this ideology applies to web pages, not to web applications.

AJAX web pages aren't first pages which would benefit from conditionally disabling "Back" and "Forward" buttons. The same issue arises for any web pages with dynamically modified content: for pages with frames, for pages with Java applets or ActiveX controls.

Even plain HTML pages generated by server-side (PHP, ASP, etc.) script often experience troubles with "Back" and "Forward" buttons. Consider a standard situation when a page uses HTML form to POST to itself, or when server-side script uses SESSIONS to save data on a server side. It immediately breaks a normal behavior of "Back" and "Forward" buttons, because document's *state* is not exclusively determined by a URL, it may depend on a session variable or even data, retrieved from a database.

So, again, such pages are web applications by themselves - something similar to a graphical Windows desktop application, and they should be able to restrict "Back" and "Forward" buttons' behavior.

Internet Explorer does provide a way to do it with onbeforeunload Event.
Unfortunately, other browser's vendors consider themselves more "purist" and do not provide such ability. If you try to Google like this you'll get a long list of messages from people struggling to disable those buttons... I understand that controlling "Back" and "Forward" buttons' behavior from a loaded HTML document may introduce some security risks, but I think that it well worth to implement as standard behavior - advantages are immense.

***************
In reply to Garret Wilson's message I said that:

Garret Wilson wrote:
> Web applications are truly applications, and it may be
> correct for them to expose certain commands to their
> runtime container (which may be a browser)

I think that you words apply perfectly to "Back" and "Forward" browser's buttons which should be controllable to certain degree by HTML document itself. If properly implemented, it would solve a lot of problems with dynamic web pages (like pages using AJAX) being not compatible with "Back" and "Forward" buttons - because they lose their state when browser leaves a page.

See Ajax Back/Forward History problem thread here and/or here.
Also take a look at Ajax Mistakes topic SourceLabs forum.

***************
After thinking about this issue and reading more articles I understood, that we should distinguish two different situations of using "Back" and "Forward" buttons:
1) To Enter/Exit current web application.
2) To travel inside current web application.

All my words above about conditional disabling of buttons apply to 1).
In 2) "Back" and "Forward" buttons are a convenient tool. I recently found an article written by Mike Stenhouse and called Fixing the Back Button and Enabling Bookmarking for AJAX Apps. It does allow to use navigation buttons inside AJAX application. But despite the fact that it's a clever code, I consider it as a hack. Just too much smart efforts for such a simple and common thing.
I wonder why it is considered better to have navigational buttons provided by a container (web browser). Coming from a windows desktop applications background (VB/Delphi) I would say, that it is oftensimplerr and more flexible to control navigation inside an application using its own tools. Speaking about web application, I would say that it is often better todisablee "Back" and "Forward" buttons inside application and to use application's custom buttons/links to go back and forth.
Unless some major changes are incorporated into modern browsers allowing to track changing state by means of AJAX.

A good website and ACRONYM and ABBR tags

I was browsing developer's sites all the day and found a site which is IMHO good for all Web developers
http://www.w3schools.com/default.asp
There are tutorials on almost all Web-related technologies!

In particular, I was surprised to find simple HTML tags I've never heart about:
ABBR and ACRONYM
http://www.w3schools.com/tags/tag_abbr.asp
http://www.w3schools.com/tags/tag_acronym.asp

Move a mouse over dotted words on this page to see how it works.

Open IE in Mozilla/Firefox Tab

If, for some crazy reason you just want to open some page not in your normal Firefox/Mozilla, but in IE...

Google rules!

I wanted to install Google Toolbar on my home machine to be able to spell check on any form - just as I did recently at work, started to look at Google pages and immediately got lost with it's endless features. I went to Google Blog Search, searched for "AJAX" and found... Guys, for example, take a look at AJAX-based slideshow here!