New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Types prevent adding new values to headers #5034
Comments
Still an issue in 1.1.2 |
I have fixed it by changing type RawAxiosHeaders = Record<string, AxiosHeaderValue>; To type RawAxiosHeaders = Record<string, AxiosHeaderValue | AxiosHeaders>; In |
I have same issue after upgrading to 1.1.2, Is there any solution behind downgrade ?! |
I fix my issue with how I set my header |
Will PR this tonight unless @salmannotkhan wants to |
I would love to create PR :) |
Can you assign this to me? |
fixes issue #5034 Co-authored-by: Jay <jasonsaayman@gmail.com>
I'm having this issue. What is the status? |
Already fixed. Can we close this issue @jasonsaayman? |
Still the same with the 1.1.13 version... |
I got this :
Axios : version 1.1.3
what's wrong ? |
i have this issue on Axios version: 1.2.1 when i use: Property 'Authorization' does not exist on type 'AxiosHeaders | Partial<RawAxiosHeaders & MethodsHeaders & CommonHeaders>'. |
I seem to able to fix it by changing possibly you need to import the AxiosHeaders |
That's really helpful! |
Wow this is a weird one |
Similar issue on
|
Any news on this? still has issue with 1.2.2 |
Hi, did you try the workaround I mentioned earlier? It works for 1.2.2 |
@pieterh Ah I just put an |
axiosInstance.interceptors.request.use(async function (config) {
config.withCredentials = true;
const token = await getAccessToken();
if (token?.bearerToken) {
config.headers = {
...config.headers,
Authorization: `Bearer ${token.bearerToken}`,
};
}
return config;
}); this worked before, but not after upgrading to v1.2.2. workaround as suggested by @xsjcTony axiosInstance.interceptors.request.use(async function (config) {
config.withCredentials = true;
const token = await getAccessToken();
if (token?.bearerToken) {
// TODO: axios bug workaround, ref: https://github.com/axios/axios/issues/5034
// @ts-expect-error
config.headers = {
...config.headers,
Authorization: `Bearer ${token.bearerToken}`,
};
}
return config;
});
|
Seems still an issue in |
I was able to fix it like this apiClient.interceptors.request.use((config) => {
const token = getToken()
if (token) {
;(config.headers as AxiosHeaders).set('Authorization', `Bearer ${token}`)
}
return config
}) Is this a common pattern? |
I think that casting to AxiosHeaders and using 'set', is a much better and sustainable solution then suppressing an unspecified error on the next line. |
I don't stand with casting. Casting, for me, just means you lie to the compiler.
|
Interesting insight. Thanks. The casting is indeed a temp solution. |
@DigitalBrainJS Hey, thanks for trying that out. |
Fixed in |
I did a pretty rough setup to make this work: interface iAxiosHeaders extends AxiosHeaders {
Authorization: string
}
instance.interceptors.request.use((request: AxiosRequestConfig) => {
request.headers = ({
Authorization: `Bearer ${token}`,
...request.headers
}) as iAxiosHeaders
return request;
}); |
Cheat Sheet ( axios.interceptors.request.use((request: InternalAxiosRequestConfig) => {
request.headers.setAuthorization(`Bearer ${token}`)
return request;
}); axios.interceptors.request.use((request: InternalAxiosRequestConfig) => {
request.headers.set('Authorization', `Bearer ${token}`);
return request;
}); axios.interceptors.request.use((request: InternalAxiosRequestConfig) => {
request.headers.set({
Authorization: `Bearer ${token}`
})
return request;
}); axios.interceptors.request.use((request: InternalAxiosRequestConfig) => {
request.headers = {
Authorization: `Bearer ${token}`,
...request.headers
} as AxiosRequestHeaders;
return request;
}); axios.interceptors.request.use((request: InternalAxiosRequestConfig) => {
request.headers = new AxiosHeaders({
Authorization: `Bearer ${token}`
});
return request;
}); axios.interceptors.request.use((request: InternalAxiosRequestConfig) => {
request.headers = AxiosHeaders.concat(request.headers, {
Authorization: `Bearer ${token}`
});
return request;
}); axios.interceptors.request.use((config: InternalAxiosRequestConfig) => {
config.headers.myHeader = 123;
return config;
}); |
This is fixed now, I guess the issue can be closed? Note that this still doesn't work: if (token?.bearerToken) {
config.headers = {
...config.headers,
Authorization: `Bearer ${token.bearerToken}`,
};
} But this works: if (token?.bearerToken) {
config.headers.setAuthorization(`Bearer ${token.bearerToken}`);
} |
This is still an issue in axios version 1.3.3 |
This is still an issue in version 1.3.4 but now @xgenem 's original solution is working |
Is this issue solved ? Should this issue be closed ? |
Yes, still an issue 👎 |
I was able to resolve the issue by casting the response like so:
|
Still an issue in v1.3.4. The errors I get:
|
The problem described in the first post has ceased to be reproduced. I'm not sure if I need to close the issue if the error persists in some scenarios. |
I think this should be unpinned, I'm at v1.4.0 and i'm not having any issues. |
The issue is still there in v1.4.0 with the type of
|
With me, the compilation error was fixed by instead of doing this:
To do this:
|
Updated the above implementation to the following to fix the issue:
|
Still experiencing some weirdness on 1.4.0 when using spread syntax instead of the set method.
The above results in
The workaround below has the desired effect:
Whilst the error message is logical and I'm fine using .set(), I'm just ditto'ing the others as it's still a change in behaviour (this didn't present any errors before updating to a newer version) |
I realize this isn't strictly related to this issue, but I didn't find any other that gets closer. Why does headers need to be an AxiosHeaders object in the first place? I used to be able to just feed it any |
@DigitalBrainJS Do we really have any requirements regarding AxiosHeaders being a class and not just a |
I have a related issue. When I use my Axios custom instance, I can set any headers, even custom ones, and they work, however when attaching an Authorization header, it's ignored
Logs the following
I attach this Authorization header through a request interceptor like most people, but on this specific case the interceptor won't attach it and I need to do it manually, however it gets ignored & not added |
I my case, i use an AxiosResponse object to test my code.
It works for me. |
October 4, 2023 my updated solution:
Edit: Above works assuming you don't previously set Authorization in your target object (which is the Edit: The following code works axios@1.51
|
You can use the following ways to set headers: Example for interceptors: import axios, { AxiosRequestConfig, AxiosHeaders } from 'axios';
const instance = axios.create();
instance.interceptors.request.use((config: AxiosRequestConfig) => {
const customHeaders = { ...config.headers } as AxiosHeaders;
customHeaders['Authorization'] = `Bearer ...`;
return {
...configs,
headers: customHeaders,
};
}); NOTE: I tried "set" and "setAuthorization" but the headers do not have these 2 functions and give an error that these 2 methods are not a function.
|
I'm using import axios from 'axios'
const instance = axios.create()
instance.interceptors.request.use(config => {
const customHeaders = {
'X-Foo': 'foo',
'X-Bar': 'bar'
}
config.headers = config.headers.concat(customHeaders as Record<string, string>)
return config
}) Instance of |
The reason for this issue is that we should not rewrite the pointers of headers, as some fields in the declaration file are mandatory rather than optional
Above is the declaration, here is the implementation
So, if you want to add your own header name, you shouldn't write it like this
It should be like this
|
Describe the bug
Types prevent adding new values to headers
To Reproduce
Expected behavior
Everything is working
Environment
The text was updated successfully, but these errors were encountered: