$http Timeout Promise: Resolution vs. Rejection Behavior

Short answer

Resolving the timeout promise cancels the request; rejecting it does nothing. In AngularJS (1.2 and later), when the promise passed via the timeout config resolves, the pending XHR is aborted and the error callback fires with status -1. When that same promise is rejected, the HTTP layer ignores the rejection entirely and the request runs to normal completion. Rejection is not a cancellation signal.

Why it works this way

The implementation attaches only a fulfillment handler to the timeout token. Conceptually, the relevant code in src/ng/http.js reduces to:

if (timeout) {
  $q.when(timeout).then(function () {
    req.abort();   // only runs on RESOLUTION
  }, angular.noop); // rejection swallowed by a no-op
}

Because the rejection path is a deliberate angular.noop, a rejected token can never abort the request. The design treats the promise as a one-shot "cancel now" event: resolution is the signal, and rejection is reserved for the token's own internal error state, which the HTTP layer chooses not to act on. This is confirmed behavior in the source, not just inference, and it has been stable across the AngularJS 1.x line since promise-based timeouts were introduced. If you are on a version earlier than 1.2, verify against your specific build, since promise handling differed in older releases.

Recommended cancellation pattern

Use a $q.defer() as a cancellation token and resolve it when the owning scope is destroyed:

angular.module('app').controller('MyCtrl',
  function ($scope, $http, $q) {
    var canceler = $q.defer();

    $http.get('/api/slow-endpoint', { timeout: canceler.promise })
      .then(function (res) { /* success */ },
            function (err) {
              if (err.status === -1) { /* aborted */ }
            });

    $scope.$on('$destroy', function () {
      canceler.resolve(); // NOT canceler.reject()
    });
  });

If several conditions should be able to cancel the request, resolve the same deferrer from any of them — resolution is idempotent for this purpose. Avoid calling reject() on the token, and do not mix a numeric timeout with a promise in the same config; the option accepts one or the other.

How to verify it yourself

1. Point $http.get at an endpoint with a server-side delay of ~10 seconds, passing { timeout: canceler.promise }.
2. After 2 seconds call canceler.resolve(): the Network tab shows the request as cancelled and the error handler receives status -1.
3. Repeat with canceler.reject(): the request completes normally and the success handler fires after the full delay.
4. Trigger $scope.$destroy() (e.g., via route change) with the resolve wired in, and confirm the pending request aborts.

One caveat worth flagging: the exact internal wiring is version-specific, so if you maintain a pinned legacy build, grep your copy of angular.js for the timeout handling in the $http factory to confirm the rejection branch is still a no-op before relying on it.