Axios interceptor config sharing issue

Request interceptor mutates config causing unexpected header in subsequent interceptor

0 reputation · 08 Jun 2023, 04:19 UTC

97.6K views0

Goal

Determine whether Axios provides an isolated config object for each request interceptor so that modifications made by one interceptor do not propagate to others in the chain.

Constraints and Uncertainty

According to the Axios documentation, request interceptors are executed in the order they are added, but it does not state whether the config argument is a fresh copy or a shared reference. If the same config object is mutated by an early interceptor, later interceptors may see the altered state, which can lead to unintended headers, authentication tokens, or base‑URL changes.

Specific questions:

Does Axios create a shallow copy of the config object for each interceptor, or does it pass the same reference through the chain?
If the config is shared, what is the recommended pattern for interceptors to safely add or modify values without affecting downstream logic?

Keep exploring this topic

Axios Interceptor Scope and Instance Isolation Limits

Exploration of the limits regarding interceptor inheritance and scope isolation when using multiple Axios instances created via axios.create().

Limits: Can Axios Interceptors Enforce Pagination Limits on Large API Responses?

Exploring whether Axios interceptors can automatically enforce pagination limits on large API responses, and what patterns or pitfalls exist when applying global request or response transformations for bounded data sets.

AbortController transition and request interceptor lifecycle in Axios v1.x

Analysis of how AbortController signals interact with the Axios request interceptor chain and the potential for pending interceptors to execute after a request is aborted.

Axios interceptors registration order and CancelToken deprecation in v1.x

Axios v1.x deprecates CancelToken in favor of AbortController, but the interceptor registration order can affect cancellation behavior. This question asks whether existing interceptors need reordering or rewriting to work reliably with the new API.

Axios passes the same config object reference through every request interceptor; it does not create a per-interceptor copy. Because headers is nested, even { ...config } leaves the original headers object shared. A downstream interceptor reading config.headers will see upstream changes, including unexpected authorization or custom headers.

Clone both levels before mutating:

axios.interceptors.request.use((config) => {
  const next = { ...config, headers: { ...config.headers } };
  next.headers['X-Request-Id'] = 'unique-id';
  return next;
});

Verify by adding one interceptor that sets a header and a second that logs config.headers; the header appears unless the first interceptor clones headers first.

Request interceptor mutates config causing unexpected header in subsequent interceptor

Goal

Constraints and Uncertainty

0 answers

Your perspective belongs here.

1 question comment