$http timeout 408

[jimmywarting]

I just used the timeout option in $http config cuz i thought it were taking to long for a simple get request to timeout on the server

$http.get("https://example.com", {
    timeout: 10000
}).catch(function(res){
    console.log(res.status); // 0
    // Here I have no idea if it timed out cuz 0 is a undocumented status code it can mean more things
    // I want to treat it the same as 408 (request timeout) as it came from the server
});

The usecase is to show a message depending on the code as in ng-switch on="res.status"

Instead i have to use $timeout and a promise instad of a simple integer and set the status code for myself

var timedout = false;
var timer = $timeout(function(){
    timedout = true;
}, 10000);

$http.get("https://example.com", {
    timeout: timer
}).catch(function(res){
    if(timedout) res.status = 408
}).finaly(function(){
    $timeout.cancel(timer);
});

Now a config with {timeout: promise} can mean anything and be canceled for any reason like "not allowed to make so many request" or whatever. But with a {timeout: 10000} we could assume it just timed out and we can set the status code to 408.

Would it make since to emulate 408 or don't we do any special treatment per request?

With simple xhr its much easier to tell if it timedout cuz you have the xhr.ontimeout event

[jimmywarting]

This lead me to another questions...
xhr.timeout = [unsigned long]
xhr.timeout can be used to cancel a requests after x seconds. $http is not using this and instead it uses a setTimeout-promise then xhr.abort. Would this be treated as the same?

1. Request get queued when making more then 6 request to the same origin... is xhr.timeout starting the countdown directly for the queued request or when request has been sent? the $http setTimeout-promise starts the countdown directly...
2. and would the $http timeout take longer then xhr.timeout if I would make the tab idle by going to another tab those makeing the setTimeout slower?
3. Wouldn't it be better to use xhr.timeout instead?

[pkozlowski-opensource]

I don't know how I feel about this one... Somehow what you are saying makes sense. At the same time I don't think we should be impersonating a back-end. Let's see what others got to say... we could do it, technically speaking... if there is enough interest in the change.

[petebacondarwin]

I think you have a reasonable point here. It is a bit of a pain to ensure that you know that the failure was due to a timeout.

While using xhr.timeout and xhr.ontimeout might be a good way forward (I need to find out why it wasn't used in the first place), we could possibly solve this by a small modification to $httpBackend. Currently a $http timeout (i.e. number or promise) will trigger xhr.abort(). This is the only bit of the $httpBackend that does this. We handle this abort here:

https://github.com/angular/angular.js/blob/master/src/ng/httpBackend.js#L89

xhr.onabort = requestError;

Perhaps we could provide a different handler than requestError to handle the abort?

[jimmywarting]

@petebacondarwin Perhaps it was when we supported IE 7 that we didn't do a xhr.timeout? It was introduced in IE8 if I'm not mistaking.

@pkozlowski-opensource I respect your decision to impersonating a back-end or not

[realityking]

I started playing around with xhr.timeout when I refactored some stuff, unfortunately it bloated the code quote a bit since all the existing code has to be kept for JSONP requests. I'll dust of my branch since there seems to be some interest.

[floofydoug]

@jimmywarting was there a consensus reached about whether an integer would be supported? In the most recent angular docs I see that number | promise could be used, however, I could only get the timeout to work if I wrapped it in a promise like your initial post.

EDIT: Sorry. I was expecting status code 408, but was getting 0. It is working as expected.

[leonardobazico]

+1