abort method
[This documentation is preliminary and is subject to change.]
Cancels the current HTTP request.
Syntax
var retval = XMLHttpRequest.abort();Standards information
- XMLHttpRequest, Section 3.6.5
Parameters
This method has no parameters.
Return value
Type: HRESULT
If this method succeeds, it returns S_OK. Otherwise, it returns an HRESULT error code.
Type: HRESULT
If this method succeeds, it returns S_OK. Otherwise, it returns an HRESULT error code.
Remarks
abort was introduced in Windows Internet Explorer 7.
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).
See also
Build date: 2/14/2012
Connection != Request
$0abort() is not supposed to close the browser *connection*; it aborts the current *request*. With HTTP1.1 keep-alive, connection and request are two very different things. A connection may be used to send/receive multiple requests, so expecting 'someRequest.abort()' to close a connection does not make sense.$0
$0$0
$0
$0That said, IE's connection management, especially wrt XHR requests, causes a lot of problems. It'd be nice if there were a way to abort them. But XMLHttpRequest.abort shouldn't be used for that.$0
- 12/29/2010
- Robert K at FB
abort() does not close the server conection!!!
For all other browsers this is not a critical issue, but for IE this is a major problem becuase it limits server conections to 2. When you have this limitation you really want the conection closed and you want it to be closed immediatly, not in a minute, not even in a seccond.
Imagine you have one connection connection doing a long polling and the other is waiting for the server to respond, but the server is too busy and the request is taking too long to complete, so you want to cancel it becuase the user is getting nervous... now what???... seems easy, isn't it? you just abort() the request in progress and just like that you have a free connection again. But this won't solve your problem, why?.. simply becuase abort() does not close the connection with the server, so you have to wait untill one of the following events occurrs: a) one hour passes since the request was made, b) the server responds, or c) the users becomes impatient and closes de browser and shows his/her middle finger to the screen. Which do you think is going to happen first?... make your bets!
And don't even think to send a third request to the server, becauses that freezes IE for ever.
If you have any other browser you just laugh out loud because you don't have silly limitations like this.
----------------------
I just finished testing this issue, and I found that the above analysis is not accurate. If you use Fiddler to monitor the HTTP traffic, you will see that the HTTP connections are still open after abort() has been called, and you will see the session completed when the server responds. However, these aborted requests will not "count" toward the server connection limit for your domain; IE will act as though they do not exist any more after abort() has been called.
You can do side-by-side tests to show that the connection limit will prevent additional requests from being made if abort() is not called and the limit is reached, and that the connection limit will not be reached if abort() is called on the last request before a new one is made.
Imagine you have one connection connection doing a long polling and the other is waiting for the server to respond, but the server is too busy and the request is taking too long to complete, so you want to cancel it becuase the user is getting nervous... now what???... seems easy, isn't it? you just abort() the request in progress and just like that you have a free connection again. But this won't solve your problem, why?.. simply becuase abort() does not close the connection with the server, so you have to wait untill one of the following events occurrs: a) one hour passes since the request was made, b) the server responds, or c) the users becomes impatient and closes de browser and shows his/her middle finger to the screen. Which do you think is going to happen first?... make your bets!
And don't even think to send a third request to the server, becauses that freezes IE for ever.
If you have any other browser you just laugh out loud because you don't have silly limitations like this.
----------------------
I just finished testing this issue, and I found that the above analysis is not accurate. If you use Fiddler to monitor the HTTP traffic, you will see that the HTTP connections are still open after abort() has been called, and you will see the session completed when the server responds. However, these aborted requests will not "count" toward the server connection limit for your domain; IE will act as though they do not exist any more after abort() has been called.
You can do side-by-side tests to show that the connection limit will prevent additional requests from being made if abort() is not called and the limit is reached, and that the connection limit will not be reached if abort() is called on the last request before a new one is made.
- 8/22/2009
- george_5154
- 8/30/2010
- Scott Trenda
How do I abort a request in IE6 ?
If this was introduced in IE7, then what is the solution for IE6 ?
- 6/15/2009
- boris.reitman
