Pourriez-vous fournir un exemple de code qui montre ce comportement ? Quel en-tête par défaut essayez-vous de supprimer ?

Si je définis axios.defaults.headers.common['Content-Type'] = 'application/json' , je ne peux pas supprimer cet en-tête pour une demande individuelle, je ne peux que le définir sur une autre valeur.

Comment avez-vous essayé de supprimer l'en-tête ? Utiliser quelque chose comme ça ?

axios.request('/path', {
  headers: {
    'Content-Type': null
  }
});

Oui. Cela n'a pas fonctionné

Désolé, j'ai raté le method dans mon exemple. Cela aurait-il pu être ce qui l'a empêché de fonctionner ?

J'ai également essayé de définir la méthode. Je soupçonne que cela a à voir avec un Object.assign() quelque part sans faire attention à la undefined .

@tyrsius quelle version d'axios utilisez-vous ? Je viens d'écrire un test pour essayer de reproduire cela et il a réussi. Je me demande si cela a pu être corrigé dans une nouvelle version.

Pour info voici mon test :

it('should remove default headers when config indicates', function (done) {
  var instance = axios.create();
  instance.defaults.headers.common['Content-Type'] = 'application/json';

  instance.post('/foo/bar/', {
    firstName: 'foo',
    lastName: 'bar'
  }, {
    headers: {
      'Content-Type': null
    }
  });

  getAjaxRequest().then(function (request) {
    testHeaderValue(request.requestHeaders, 'Content-Type', null);
    done();
  });
});

J'ai eu ce problème également.
J'essaie de supprimer l'en-tête 'Authorization' de 'common' mais le seul moyen que j'ai trouvé pour le faire fonctionner est de supprimer la propriété de axios.defaults.header, de faire la demande, puis de rajouter la propriété encore.
Ce sera plus facile quand ce bug sera corrigé

C'est également un problème pour moi (avec axios v0.14.0), en particulier pour les points de terminaison qui utilisent Access-Control-Allow-Headers , auquel cas je dois m'assurer que certains en-têtes ne sont pas du tout envoyés avec la demande.

j'utilise la version 15.2 et quand je le fais

headers: {
      'Content-Type': null
    }

il définit la valeur de l'en-tête sur null. mais j'ai vraiment besoin que le nom de l'en-tête soit complètement supprimé.

par exemple, lors de l'utilisation de s3 et de la génération d'une URL présignée pour publier un fichier dans un compartiment, vous ne pouvez pas avoir d'en-tête Authenticate. mais j'ai une autorisation par défaut définie car la grande majorité de mes demandes l'exigent pour ma propre API.

la façon dont j'ai contourné cela est de faire ce qui suit

    var instance = axios.create();
    instance.defaults.headers.common = {};

    instance.put(signedUrl, file, {headers: {'Content-Type': file.type}})
        .then(function (result) {
            console.log(result);
        })
        .catch(function (err) {
            console.log(err);
        });

Edit : cela ne fonctionne pas comme prévu. le problème est que lorsque vous effacez les en-têtes

instance.defaults.headers.common = {};

il le supprime au niveau mondial. cela me déconnectera car j'utilise un en-tête pour Auth.

pour contourner ce problème jusqu'à ce qu'il y ait une meilleure façon de gérer la configuration globale, je transmets les en-têtes requis à chaque appel, ce qui n'est pas idéal.

545

J'ai eu le même problème mais résolu avec

delete axios.defaults.headers.common["Authorization"]; // or which ever header you have to remove

J'ai la situation exacte en tant que @SepiaGroup
J'ai essayé de l'écraser avec null et '' mais AWS voit alors null comme mon autorisation et se plaint.
J'ai essayé de le supprimer de l'instance, mais mon autorisation est supprimée globalement, j'obtiens donc 403 sur mon propre serveur.

Je suppose que ma solution de contournement sera d'utiliser un vieux XHR pour cela mais cela me rend triste :(

+1 Également bloqué dans l'impossibilité d'effacer l'en-tête par défaut pour un appel spécifique.

+1

+1

Je constate également ce comportement dans la dernière version (0.16.2). La tristesse s'ensuit :(

il suffit de le supprimer

delete instance.defaults.headers.common.Authorization
````

the way below is not working.
----
I think we could create a logout method that recreate the axios instance to replace the old one.

let instance = axios.create({options})

fonction : déconnexion () {
instance = axios.create({options})
}
```

@lzp4ever cela fonctionnerait dans la plupart des cas, je suppose. Mais dans les cas où quelqu'un a ajouté des intercepteurs de demande et de réponse, ou fait plus de configuration de l'instance au-delà de la simple transmission d'options de configuration, votre approche n'exigerait-elle pas que tout cela soit refait ?

Je me demandais simplement si la solution de @axelgenus est plus propre et nécessite moins de "réinitialisation" d'une instance Axios entière à partir de laquelle vous essayez de supprimer un en-tête personnalisé particulier.

Ce serait bien de ne PAS envoyer l'en-tête par défaut sans supprimer les propriétés :)

+1

+1

+1. Il semble triste que vous ne puissiez pas supprimer les en-têtes d'une instance. Cela signifie que toutes les instances ont une référence à la variable globale.

+1

+1

+1 Veuillez résoudre ce problème.

+1

+1

+1

Nous rencontrons le même problème. La plupart des applications frontales que nous créons doivent utiliser plusieurs services Web Rest. L'impossibilité de désactiver l'en-tête de sécurité est un gros problème pour nous.

+1

+1

Essayez ces gars sur un objet de demande spécifique, avec des en-têtes, des données et une méthode :
transformRequest(data, headers) { delete headers.common.Authorization; return data; }

Essayez ceci, cela résout mon problème :

supprimer axios.defaults.headers.common["Autorisation"] ; // et créez vos propres en-têtes

@mukeshyadav Cette solution a été mentionnée plusieurs fois plus haut dans ce fil.

Le point soulevé est que ce n'est pas nécessairement la solution idéale. Imaginez un scénario dans lequel vous avez ajouté vos propres intercepteurs de requête/réponse personnalisés à une instance Axios, mais vous souhaitez qu'une requête spécifique n'inclue pas les en-têtes utilisés partout ailleurs, vous devrez supprimer le ou les en-têtes et les rajouter après la demande est terminée.

À l'inverse, se demander s'il existe un moyen de dupliquer simplement une instance Axios avec une relative facilité à utiliser dans ces types de cas ponctuels.

+1

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

travaille pour moi

@aaronatmycujoo Cela semble être la solution la plus sexy ici. Cependant, je me demande si la suppression de l'en-tête comme celle-ci le supprime d'une instance Axios plus haut dans la chaîne. Vous devrez peut-être créer une copie complète de headers ou quelque chose du genre.

Faudra que je teste ça.

d'après ce que je peux dire, ce n'est pas le cas. bien qu'il puisse y avoir un cas limite que je ne déclenche pas

@SepiaGroup, vous n'avez pas besoin d'ajouter des en-têtes dans l'ensemble de vos demandes... Faites ceci :

axios.defaults.headers.common = {};
axios.defaults.headers.common.accept = ‘application/json’;

Et dans les en-têtes de demande, vous ne verrez que 'application/json'

+1 merci @axelgenus votre solution a fonctionné

+1

@aaronatmycujoo FTW !!! Sa solution a fonctionné comme un charme... ty !

Confronté au même problème lors de la tentative de téléchargement de fichiers sur S3 (n'autoriser qu'un seul mécanisme d'authentification).
J'ai essayé la solution de
@aaronatmycujoo Cette solution fonctionne parfaitement pour moi ! ??
Merci les gars d'avoir sauvé ma journée!

+1

+1

+1

axios.defaults.headers.common = {};
axios.defaults.headers.common.accept = ‘application/json’;

Fonctionne très bien pour moi !!!

Je ne sais pas si c'est de notoriété publique, mais il existe un ensemble d' "en-têtes interdits" , qui ne peuvent pas être supprimés.

• Accept-Charset
• Accept-Encoding
• Access-Control-Request-Headers
• Access-Control-Request-Method
• Connection
• Content-Length
• Cookie
• Cookie2
• Date
• DNT
• Expect
• Host
• Keep-Alive
• Origin
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• Via

Erreur

TypeError : impossible de convertir un objet non défini ou nul en objet

delete axios.defaults.headers.cummon["Authorization"];

Vous avez une faute de frappe @putu-eka-mulyana et je pense que ce n'est pas le bon endroit pour signaler un tel problème.

delete axios.defaults.headers.common["Authorization"];

+1, supprime le jeu de caractères du type de contenu

+1, supprime l'en-tête Auth pour une seule demande, prend en charge l'objet de configuration de la demande sans le supprimer explicitement, juste en passant une valeur comme undefined ou null

+1, supprime l'en-tête Auth pour une seule demande, prend en charge l'objet de configuration de la demande sans le supprimer explicitement, juste en passant une valeur comme undefined ou null

J'ai une demande OPTION avant ma demande PUT, donc la solution transformRequest de @aaronatmycujoo a fonctionné pour ma demande OPTION, mais l'en-tête d'autorisation était toujours appliqué à ma demande PUT.

En fin de compte, j'ai fini par créer des instances distinctes pour les demandes d'authentification et les demandes publiques, de sorte que mon en-tête d'authentification n'a été appliqué qu'à l'instance d'authentification.

// do not configure auth header
export const publicAxios = axios.create(...)

// configure auth header
export const authAxios = axios.create(...)

// no auth header present for public instance
publicAxios.put(...)

@rizen PR #1845 par @codeclown permettrait de null . Cela résoudrait-il le problème ?

@rizen PR #1845 par @codeclown permettrait de null . Cela résoudrait-il le problème ?

Oui

Quel long voyage. J'espère que le #1845 sera fusionné dès que possible.

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

À partir de la documentation axios :

> Ceci n'est applicable que pour les méthodes de requête 'PUT', 'POST', 'PATCH' et 'DELETE'

Je rencontre une situation assez similaire mais avec une requête GET :

1. OBTENEZ http://www.saasserviceprovider.com/notpublicapi avec un en-tête de Authorization: Bearer mytoken

1. Redirige vers le point de terminaison AWS S3. L'URL de redirection a une chaîne de requête : X-Amz-Signature=blahblahblah ajoutée.

2. AWS S3 rejette l'appel car deux authentifications :

   • En-tête : Authorization bearer token
   • Chaîne de requête : X-Amz-Signature=blahblahblah

Ni transformRequest , transformResponse , axios.interceptors.request , axios.interceptors.response semblent pouvoir me permettre de m'injecter dans le processus et de supprimer temporairement l'en-tête d'autorisation lorsque j'appuie sur le redirection vers AWS S3 - vraisemblablement, si je pouvais entrer après une redirection, je pourrais faire quelque chose pour effectuer delete headers.Authorization .

Même appel avec la demande api/postman/etc fonctionne.

"Solution de contournement":

C'est un point de vente à la vapeur laid et inefficace... mais mais ça "fonctionne ™". Est-ce que je reçois un financement VC maintenant?

  let retry = false;
  await axios({
    method: 'get',
    url: "http://www.saasserviceprovider.com/notpublicapi",
    headers: {
      'Authorization': "Bearer mytoken",
    }
  })
  .then((r) => {
    //return successful
  })
  .catch ((e) => {
    if (e.request.res.responseUrl.match(/s3.amazonaws.com/)) {
      retry = e.request.res.responseUrl;
    } else {
          //log error
    }
  })

  //Retry
  if (retry) {
    await axios.get(retry)
    .then((r) => {
        //return successful
      }
    })
    .catch((e) => {
       //log error
    })
  }

Sérieusement, ça doit être mieux (dans les axios)

Je rencontre une situation assez similaire mais avec une requête GET :

1. OBTENEZ http://www.saasserviceprovider.com/notpublicapi avec un en-tête de Authorization: Bearer mytoken
2. Redirige vers le point de terminaison AWS S3. L'URL de redirection a une chaîne de requête : X-Amz-Signature=blahblahblah ajoutée.
3. AWS S3 rejette l'appel car deux authentifications :

• En-tête : Authorization bearer token
• Chaîne de requête : X-Amz-Signature=blahblahblah

Ni transformRequest , transformResponse , axios.interceptors.request , axios.interceptors.response semblent pouvoir me permettre de m'injecter dans le processus et de supprimer temporairement l'en-tête d'autorisation lorsque j'appuie sur le bouton redirection vers AWS S3 - vraisemblablement, si je pouvais entrer après une redirection, je pourrais faire quelque chose pour effectuer delete headers.Authorization .

Même appel avec la demande api/postman/etc fonctionne.

Sérieusement, ça doit être mieux (dans les axios)

@iyerusad Avez-vous trouvé un meilleur moyen que votre solution de contournement ? Je suis confronté au même problème et il est frustrant de ne pas pouvoir intercepter la redirection et supprimer l'en-tête d'autorisation uniquement pour cette demande de suivi/redirection (vers amazon dans ce cas) 🤔

@iyerusad Avez-vous trouvé un meilleur moyen que votre solution de contournement ? Je suis confronté au même problème et il est frustrant de ne pas pouvoir intercepter la redirection et supprimer l'en-tête d'autorisation uniquement pour cette demande de suivi/redirection (vers amazon dans ce cas) 🤔

Pas vraiment - en utilisant l'option B. ci-dessous.

_Les options que j'ai évaluées :_
A. Adoptez un wrapper/client alternatif (par exemple, fetch api? request? request semble fonctionner mais est apparemment obsolète). C'est peut-être l'option la plus propre, mais cela signifie passer à une autre syntaxe client http.

B. Enveloppez ma solution de contournement dans une fonction et utilisez cette fonction pour les demandes qui, je le sais, rencontrent ce problème - moche apparemment moins efficace, mais je l'utilise pour le moment.

C. J'espère que je suis un idiot et que j'utilise mal axios et qu'il existe une solution de contournement plus saine avec axios.

D. Axios obtient-il un correctif/correctif ?

@mikhoq @iyerusad Voulez-vous ouvrir un nouveau numéro pour suivre votre problème ? Parce qu'il est différent de l'actuel, qui a peut-être été corrigé en #2844.

Pas de problème - Ouvert #2855.

@mikhoq, veuillez y ajouter un commentaire si vous avez un point de terminaison de repro public.

Donc apparemment, transformRequest est appelé pour des requêtes GET ? J'ai essayé cela et cela a fonctionné, cela n'a supprimé que l'en-tête de la demande en cours.

transformRequest: [(data, headers) => {
    delete headers.common.Authorization
    return data
}]

Mais les docs disent

// transformRequest permet de modifier les données de la requête avant qu'elles ne soient envoyées au serveur
// Ceci n'est applicable que pour les méthodes de requête 'PUT', 'POST', 'PATCH' et 'DELETE'

Ce qui m'a fait penser que transformRequest ne serait pas appelé pour les requêtes GET , mais c'est le cas. Alors, que signifie réellement cette ligne ?

"Cela ne s'applique qu'aux méthodes de requête 'PUT', 'POST', 'PATCH' et 'DELETE'"

Peut-être, "Ceci n'est potentiellement utile que pour ...." ....? C'est trompeur imo.

cela marche:
en-têtes : {
« type de contenu » : « application/json »,
'Autorisation' : nulle,
}

J'ai essayé de régler { headers: { 'Content-Type' = null } } sans succès,
donc pour ajouter au commentaire utile de @axelgenus , je devais aller un peu plus loin :

import Axios from 'axios'
const client = Axios.create({
  // ...
  transformRequest: [(data, headers) => {
    // add required "Content-Type" whenever body is defined
    if (data) headers['Content-Type'] = 'application/x-www-form-urlencoded'
    return data
  }],
})
// completely remove "Content-Type" from instance by default
delete client.defaults.headers.common['Content-Type']
delete client.defaults.headers.post['Content-Type']
delete client.defaults.headers.put['Content-Type']
delete client.defaults.headers.patch['Content-Type']
// ...

Le cas d'utilisation consistait à implémenter la couche de requêtes pour la méthode d'authentification Bitstamp API V2 .