2
votes

The documentation mentions you may define 4 functions for an interceptor and it says:

There are two kinds of interceptors (and two kinds of rejection interceptors):

request: interceptors get called with a http config object. The function is free to modify the config object or create a new one. The function needs to return the config object directly, or a promise containing the config or a new config object.

requestError: interceptor gets called when a previous interceptor threw an error or resolved with a rejection.

response: interceptors get called with http response object. The function is free to modify the response object or create a new one. The function needs to return the response object directly, or as a promise containing the response or a new response object.

responseError: interceptor gets called when a previous interceptor threw an error or resolved with a rejection.

I only have one interceptor defined. And I noticed that if the response HTTP code is 403, then the responseError function gets invoked. I'm not sure what else might trigger it. Where in the documentation does it say something about when do these 4 functions get invoked? Please cite any reputable sources.

It says:

"... when a previous interceptor threw an error or resolved with a rejection"

When does it throw an error or how does it resolve with a rejection? I need more elaboration on this part.

1

1 Answers

3
votes

Well, as you might expect...

request interceptors are fired before a request is sent to the server (and of course before the data is transformed using the transformRequest function).

requestError interceptors are fired when there is a request error, i.e. if any of the previous request interceptors threw an error or returned a promise that get's rejected.

response interceptors are fired as soon as the response arrives from the server. Note that response interceptors are fired in reverse registration order.

responseError interceptors are fired when the HTTP status code indicates an error (i.e. it is not a redirect and is outside of the [200-299] range) or when any of the previous response interceptors threw an error or returned a promise that get's rejected.


A key point is that any of the above methods can return either an "normal" object/primitive or a promise that will resolve with an appropriate value. In the latter case, the next interceptor in the queue will wait until the returned promise is resolved or rejected.

In this context, throwing an error refers to plain, old JavaScript error. E.g. trying to access a non-existing method (myObj.methodThatDoesNotExit()) or explicitly raising an exception (throw Error()).

A rejected promise can be created either by returning $q.reject(someObj) or by calling .reject(reason) on the deferred object whose promise was returned.


As the documents state, it is important that "before you start creating interceptors, be sure to understand the $q and deferred/promise APIs".


The relevant parts of the source code (v1.2 branch - current version 1.2.16), where interceptors are handled are in ng/http.js:

line 127 - line 155
line 685 - line 724