Interceptors have unparsable headers by axios

[jmarianski-kogifi]

Describe the bug

When using interceptors to possibly retry a request with the same configuration (without any changes) one would think that using the same config as before would lead to the perfectly retried request. However, creating a request that way leads to headers missing due to the incorrect parsing of the AxiosConfig object. Headers get parsed into [object Object] instead of the flattened object or simply passed through as valid argument for headers.

The same bug appears when using https://www.npmjs.com/package/axios-retry

Example error when missing headers after retry happens:

To Reproduce

try using this error interceptor with a small change:

const retryInterceptor = (err: AxiosErrorRetriable) => {
	console.log(err);
	const { config, message } = err;
	if (typeof config.retry === "undefined") {
		config.retry = 10;
	}
	if (!config || !config.retry) {
		return Promise.reject(err);
	}
	// retry while Network timeout or Network Error
	if (
		!(message.includes("timeout") || message.includes("Network Error")) ||
		message.includes("canceled")
	) {
		return Promise.reject(err);
	}
	config.retry -= 1;
	const delayRetryRequest = new Promise<void>(resolve => {
		setTimeout(resolve, 1000);
	});

	return delayRetryRequest.then(() => {
		const retryInstance = axios.create();
		retryInstance.interceptors.response.use(undefined, retryInterceptor);

		return retryInstance.request({
			...config,
			headers: JSON.parse(JSON.stringify(config.headers)),
		});
	});
};

instead of parsing headers in retryInstance like here, pass them directly (so that the AxiosHeader object is passed).

In order to test it in some capacity try having a backend server with upload capabilities and filters out by data types. Therefore you are required to provide a ContentType with a request. Add other headers in the original request. We do that because of a support for multipart

In order to test the connection reset we've added the containers in the docker network and use chrome throttling to allow ourselved to upload small files. In case we want to simulate the network to fail we simply plug out a container from the internal network by using docker network disconnect and then reconnect to see the "correct" retry.

The console.log in the first line shows that AxiosCondig after the first retry contains single key [object Object].

---

Additional screenshot:

Code snippet

No response

Expected behavior

Perhaps if headers variable contains a type of AxiosConfig pass it through unchanged?

Axios Version

1.1.3

Adapter Version

No response

Browser

Chrome

Browser Version

No response

Node.js Version

No response

OS

Linux mint

Additional Library Versions

No response

Additional context/Screenshots

We were sending data via a post request to specified url with a blob of data with an abort controller and headers signifying the size of blob and internal upload index like in the screenshot above. After error the config is correct as in containing AxiosConfig with correct keys. However sending a request with the same config (albeit changed a bit to contain the retry variable) lead to headers being improperly parsed and request is sent without the headers, and therefore the returning config - regardless if it was a connection or other error - returns wrong.

[jasonsaayman]

Hi 👋

Please try the latest pre-release by running the following:

npm i axios@1.2.0-alpha.1

Please provide feedback in either the pinned issue or discussion thread 🧵