On my last post [1] 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).