On my last post I wrote about some common mistakes when upgrading your web application to an AJAX enabled one. I got a great feedback on this post... and a couple of developers wrote something like "Don't use Microsoft products!" or "Use JSP instead of ASPX and you are fine...!".

As I understand the problem there is no difference between all the frameworks, web servers and server-side programming language. When using the XMLHttpRequest object I have the method .abort() to kill an http request. I don't know what is done internal, is it similar to remove the network cable? If there is any http request the web server will read the http header and maybe a http body. After this progress the web server will prepair (or already started to prepair) the http response and send back the http header and response. Finished this the http connection is closed, maybe the TCP/IP connection is still alive (depends on the Keep-Alive settings). During all the time it is possible that someone aborts the connection (for me it is more a kill instead of a cancel which means, there is nothing possible to do during or right after this action).

A web server that has already started processing the requests will not get this information. Think of an long running SQL batch that will run in a different process maybe on a different server not knowing anything about web server, TCP/IP or JavaScript inside a web browser.

Do we need something like a TransactionScope in (AJAX) web applications? Do we want to commit or rollback our changes if we lost the connection only for the result code? As I can remeber there is a project using the http status code 100 continue to do exactly this.

I'd like to get your opinion and what do you think about connection aborts (or that the web browser is not available any more).

1 Comment

• Kevin Davis said Tuesday, November 21, 2006 4:28:33 PM

  In MSDN it states: The abort method interrupts an asynchronous operation in progress. (Pass true to the varAsync parameter of open to create an asynchronous request.) Calling abort resets the object; the onreadystatechange event handler is removed, and readyState is changed to 0 (uninitialized). Of course when you make asynchronous calls, once they are sent, they are on their own. As I understand it, the XMLHttpRequest Object is in a readystate until it receives a response from its sent call. If not properly monitored, a user could theoretically be left waiting an infinite amount of time for the response. As programmers, we need to mindful of the readystate and the consequences if we do not manage our acynchronous calls. If it fails, we programmers have to manage the state of the server processes and handle any transactions. As for the http status code 100, in short, it is an interim response from the server used to inform the client that the initial part of the request has been received and is willing receive the request body based on the request headers. Aloha, Kevin Davis