Axios: Application de type de contenu/x-www-form-urlencoded

Créé le 28 juin 2016  ·  220Commentaires  ·  Source: axios/axios

Essayez d'envoyer une demande avec le type de contenu application/x-www-form-urlencoded

var data = Querystring.stringify({ 
                "grant_type": "password",
                "username": login,
                "password": password
            });
axios.post(Urls.login, data);

mais il n'y a pas un tel en-tête dans la demande.

J'ai essayé d'utiliser le code :

  var data = Querystring.stringify({ 
                "grant_type": "password",
                "username": login,
                "password": password
            });
        return axios({
            method: 'post',
            url: Urls.login,
            data: data,
            headers: {
                'Content-type': 'application/x-www-form-urlencoded'
            }
        });

même problème

le code jquery fonctionne bien :

$.ajax({
            url: Urls.login,
            data: data,
            type: "POST",
            headers: {
                'Content-type': 'application/x-www-form-urlencoded'
            }
        });

Comment puis-je utiliser axios pour envoyer une requête avec cet en-tête ?

Commentaire le plus utile

Vous pouvez utiliser une bibliothèque comme qs à la place :

var qs = require('qs');
axios.post('/foo', qs.stringify({ 'bar': 123 });

Tous les 220 commentaires

Cela devrait fonctionner comme vous l'avez montré. Cela ressemble à un bug. Je vais me renseigner.

La cause, ce sont les intercepteurs. Je ne peux pas envoyer de requête avec ce type de contenu uniquement lorsque j'utilise des intercepteurs.

Voici mon code :

axios.interceptors.request.use(function (config) {
        var token = LoginStore.getJwt();
        if (token) {
            config.headers["Authorization"] = "Bearer " + token;
        }

            return config;
        }, function (error) {    
            return Promise.reject(error);
        });

À l'intérieur de l'intercepteur, je peux voir l'en-tête 'Content-Type', mais il n'est pas envoyé au serveur.
Est-ce que j'utilise correctement les intercepteurs ?

Des mises à jour à ce sujet ? J'ai le même problème. Axios n'envoie pas l'en-tête que j'ai défini.

Cela semble être la ligne coupable → https://github.com/mzabriskie/axios/blob/master/lib/adapters/xhr.js#L117

Avez-vous une idée de la raison pour laquelle l'en-tête Content-Type est supprimé avant l'envoi de la requête ?

Une solution de contournement consiste à changer votre data en data || {} lorsque vous faites une demande axios. Cela garantira que les données ne sont pas indéfinies.

Il semble que la logique pour supprimer Content-Type lorsque requestData est undefined est venue dans ce commit https://github.com/mzabriskie/axios/commit/9096d34186d5a5148f06c07854b21d6cc8035e96. Cependant, rien n'indique pourquoi il a été ajouté.

Je voterais si le requestData est undefined et la méthode est PUT , POST ou PATCH et aucun Content-Type n'a été défini, alors Content-Type par défaut à application/x-www-form-urlencoded . Sinon, respectez simplement ce qui a été spécifié.

@mzabriskie Mais dans l'extrait de code fourni par @alborozd , le data est défini sur Querystring.stringify({...}) , donc requestData ne devrait pas être undefined , n'est-ce pas?

@mzabriskie je pense que tu as raison. Lorsque j'utilise un intercepteur de requêtes, le violoneur indique que les données sont vides. Sans intercepteur, je peux voir les données et l'en-tête et cela fonctionne bien.

Donc, le problème survient probablement lorsque vous travaillez avec des intercepteurs.

Aucun intercepteur n'est nécessaire pour planter cette chose. J'ai défini les valeurs par défaut de l'en-tête de type de contenu axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded'; et je ne peux envoyer aucune charge utile dans le corps POST.

J'ai utilisé une solution de contournement avec URLSearchParams :

    var params = new URLSearchParams();
    params.append('email', email);
    return (dispatch) => {
        axios.post('/stack/' + uri, params)

Mais cela n'est pas pris en charge par Safari et IE.

Edit : Ok :) Prochaine mise à jour sur la solution de contournement. La solution de contournement entièrement prise en charge consiste à envoyer des données sous forme de chaîne de requête.
data: "flashcard=" + JSON.stringify(flashcard) + "&stackUri=" + stackUri . Ça fait mal, mais ça marche 👍

Vous pouvez utiliser une bibliothèque comme qs à la place :

var qs = require('qs');
axios.post('/foo', qs.stringify({ 'bar': 123 });

Ce n'est pas une solution. Quelle est la différence si j'utilise "Querystring" ou "qs" ? Le problème est que l'en-tête ['Content-Type'] = 'application/x-www-form-urlencoded' est vide à cause des intercepteurs.

Des mises à jour ici ? Parce que j'ai perdu 1h aujourd'hui à rechercher pourquoi mes POST n'affectent pas l'API (jusqu'à ce que je me souvienne de ce problème) ... Ou il n'y a pas de plan pour résoudre ce problème et il vaut mieux aller ailleurs?

J'ai le même problème... j'attends toujours la solution...

Veuillez rouvrir @nickuraltsev car cela n'est pas résolu par votre solution.

+1 pour le problème.

J'utilise un intercepteur avec la bibliothèque qs pour résoudre ce problème. Fonctionne bien pour moi.

import qs from 'qs';

axios.interceptors.request.use((request) => {
  if (request.data && request.headers['Content-Type'] === 'application/x-www-form-urlencoded') {
      request.data = qs.stringify(request.data);
  }
  return request;
});

+1 pour le problème.

hyanmandian a commenté il y a 14 heures
J'utilise un intercepteur avec la bibliothèque qs pour résoudre ce problème. Fonctionne bien pour moi.

Génial, mais ce n'est pas un moyen de résoudre le problème dans les bibliothèques à mon humble avis en en installant un autre.

Vous pouvez simplement ajouter un data: {} à la configuration, afin que l'intercepteur n'ignore pas les en-têtes que nous spécifions.

C'est ce que j'ai fait, et cela a fonctionné pour moi:

import request from 'axios'

export const playSound = (soundFile) => (dispatch) => {
    dispatch(playSoundPending());
    return request
    .get(`/play/audio/${soundFile}`, { headers: {'Content-Type': 'audio/x-wav'}, data: {} })
    .then(response => response.data)
    });
};

Cela a changé le Content-Type de application/json à audio/x-wav pour moi dans les en-têtes de requête dans l'onglet réseau.

Cela a-t-il déjà été corrigé ? Je n'arrive pas à définir mon type de contenu avec l'une des solutions publiées ici.

J'ai le même problème, une aide ?

J'ai résolu le problème en utilisant encodeURIComponent :

getToken statique (nom d'utilisateur, mot de passe) {
retour axios({
méthode : 'post',
URL : 'points de terminaison',
données : Username=${**encodeURIComponent**(username)}& password=${**encodeURIComponent**(password)}& Grant_type=password
})

cogner. On supposerait certainement que si l'on définit des valeurs par défaut, elles seront toujours respectées. Axios ignore définitivement les valeurs par défaut dans certains contextes, ce qui cause des problèmes aux pauvres.

Voici une fusion plus spécifique où cela s'est produit : https://github.com/mzabriskie/axios/pull/195/files

+1 pour ce problème.
J'ai passé plus de 3 heures à essayer de comprendre ce qui ne va pas avec ma configuration Tomcat et apparemment, mes en-têtes ont été volés sur le chemin du serveur. Les solutions de contournement n'ont pas aidé. Dieu sauve les en-têtes !

@polyakoff comment avez-vous résolu cela? Ou êtes-vous toujours bloqué. Ce que j'ai observé, c'est que ce problème se produit par intermittence

@usopan Toujours coincé.

Je suis passé à isomorphic-fetch pour cette demande particulière comme solution de contournement.
Les choses semblent fonctionner correctement sur la plupart des navigateurs, mais ne fonctionnent toujours pas sur certaines versions de Safari.
Je commence à penser que Safari me baise.

+1 pour ce problème.

J'ai trouvé la solution. La solution consiste à détecter le navigateur.
Dans Chrome, utilisez - https://github.com/ljharb/qs pour analyser les données json en chaîne et définir l'en-tête Content-Type
Dans Safari, utilisez - FormData comme corps et ne définissez aucun en-tête Content-Type

Je ne peux pas imaginer comment un problème comme celui-ci n'est pas résolu depuis plus de six mois déjà.

wow belle question! toujours en attente de la mise à jour ☕️

ça craint.

c'est nul +1

+1

+1

+1

+1

+1

+1

+1

+1

+1

const chaîne de requête = require('querystring');

connexion(){
var _this = ceci ;
ceci.$http({
URL : URL,
méthode : 'post',
données : querystring.stringify({
e-mail : e-mail,
mot de passe : pass
}),
en-têtes : {
'Content-Type' : 'application/x-www-form-urlencoded'
}
}).then(fonction (réponse) {
console.log(réponse);
}).catch(fonction (erreur) {
console.log (erreur);
});
}

+1

+1

+1

Donc, pour résumer, toutes les requêtes envoyées avec Content-Type: application/x-www-form-urlencoded sont :

  • Ne pas encoder automatiquement la charge utile
  • Ne pas définir l'en-tête même s'il a été spécifié

La solution de contournement, pour l'instant, définit le data: {} pour que l'en-tête soit défini et encode manuellement la charge utile des données de la demande

Je partage mon code :

import qs from 'qs'
...

const instance = axios.create({
  baseURL: config.api.host,
  responseType: config.api.responseType,
  timeout: config.api.timeout,
  data: {},
})

instance.interceptors.request.use((req) => {
  if (req.method === 'post') {
    req.headers['Content-Type'] = config.api.defaults.postContentType
    req.data = qs.stringify(req.data)
  }

  return req
}, (error) => Promise.reject(error))

Cela semble fonctionner pour moi

Bonjour gars! Je me demande si je dois créer un fork et fournir une solution avec une petite méthode native d'analyse des requêtes? Sera-ce un bon "modèle" pour les créateurs ? @mzabriskie Aimeriez-vous intégrer une telle chose ?

passer plus de 3 heures pour résoudre ce problème .. @ Maxwell2022 pouvez-vous s'il vous plaît coder avec des exemples de données?

+1

1

+1

@bsjaffer J'ai posté l'exemple de code, que voulez-vous d'autre ?

@ Maxwell2022 je suis bien avec ça maintenant.

+1

+1

+1

+1

+1

+1

+1

++1

Faites-le, j'espère que cela vous aidera.

let details = {
      key1: 'data1',
      key2: `data2`,
      key3: `data3`,
    };

    var formBody = [];
    for (var property in details) {
      var encodedKey = encodeURIComponent(property);
      var encodedValue = encodeURIComponent(details[property]);
      formBody.push(encodedKey + "=" + encodedValue);
    }
    formBody = formBody.join("&");

    const URL = `PUT-YOUR-API-URL-OVER-HERE`;
    return axios({
      method: 'POST',
      url: URL,
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded',
      },
      data: formBody,
    })
    .then(res => res.data)
    .catch(error => { throw error });

+1

Oui, vous l'avez deviné, +1

+1

+1

+1, la solution de reznord a fait la magie (définir les données à côté des en-têtes) :
const config = { headers: { 'Content-Type': 'multipart/form-data' }, data: {} };

@bruddah cool, content que ça ait fonctionné.

_Envoyé depuis mon OnePlus ONEPLUS A3003 via FastHub _

+1

L'utilisation de qs fonctionne pour moi!

Dans React, cela a fonctionné pour moi:

import axios from 'axios';
import querystring from 'querystring';

const data = querystring.stringify({id:32, name:'john'});
axios.post('http://example.com/posturl', data)

La raison en est qu'axios n'encode pas automatiquement les données de publication avant de les ajouter au corps de la requête HTTP, elles doivent donc être encodées avant d'envoyer la requête. C'est ce que fait la chaîne de requête. Cela prend {id:32, name:'john'} et produit quelque chose comme id=32&name=john , puis axios le définit comme corps de la demande de publication.

Vous pouvez tester cela en faisant la requête suivante :

axios.post('http://example.com/posturl', 'id=32&name=john')

Cela devrait avoir le même résultat que le code ci-dessus.

toujours pas réparé plus d'un an depuis l'ouverture....

+1

+1

Salut les gars! Vous pouvez essayer ceci, cela fonctionne bien pour moi, mais je ne sais pas pourquoi.

get (url, data) {
    return axios({
      method: 'get',
      url: url,
      baseURL: 'http://xxxxx/api',
      timeout: 10000,
      headers: {
        'Content-Type': 'application/x-www-form-urlencoded; charset=UTF-8'
      },//this is important !
      data: data,//this is important !
      params: data//this is important !
    }).then(
      (response) => {
        console.log(response)
        return checkStatus(response)
      }
    )
  }

Essayer d'envoyer _Content- Type:application/json-patch+json_ dans une demande de correctif (suivant RFC6902 ),
ce qui suit a fonctionné pour moi (j'ai le bon type dans les en-têtes de requête):

axios.patch(
          url,
          data,
          { headers: { 'Content-Type': 'application/json-patch+json;charset=UTF-8' } }  
          ))

Pour ceux qui ont ce problème parce que l'intercepteur écrase les en-têtes, utilisez simplement dans votre intercepteur :

config.header['yourheader'] = value;

au lieu de

config.header = {'yourheader': value}

La solution @ DavidJiang7 devrait fonctionner

Cela fonctionne pour moi:

static register(token, email, lang)
{
        let config = { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }; // we do it to send SIMPLE post eequest (to avoid send CORS OPTIONS request before post)
        let params = new URLSearchParams(); // and we cannot send json but params are transform to  url-style
        params.append('email', email);
        params.append('lang', lang);

        return axios.post(ENV.API_URL + '/device/' + token + '/register', params, config);
}

Image intéressante montrant des cas CORS ICI . La demande OPTIONS ne sera pas envoyée lorsque nous enverrons une demande SIMPLE. Une demande simple est une demande qui est GET, HEAD, POST et dont l'en-tête 'content-type ' est égal à application/x-www-form-urlencoded , multipart/form-data ou text/plain et tout en-tête personnalisé.

Fais juste ça

const data = {name: 'my name'}
const form = 'data=' + JSON.stringify(data)
axios.post('/my_url', form)

Édité
désolé pour la faute de frappe. et ça marche pour moi, je l'utilise depuis des mois.
J'ai oublié de mentionner que dans le serveur, vous n'avez que le data

...
 $data = json_decode($_POST['data'], 1);
 echo $data['name']; // my name
...

bosse pour une solution propre, prêt à aider aussi.

@jesusantguerrero
Fais juste ça

données const = {nom : 'mon nom'}
formulaire const = 'data=' + JSON.stringfy(data)
axios.post('/mon_url', formulaire)

ne fonctionne pas, mais c'est JSON.stringify ^^ faute de frappe ci-dessus.

Pour ceux d'entre vous qui utilisent Node.js, cela fonctionne. Merci à tous dans le fil, j'ai essentiellement combiné un tas de solutions populaires et fait référence aux documents Node.js

C'est le plus propre que j'ai pu trouver.

import { URLSearchParams } from 'url';

async function auth() {
  try {
    const config = {
      headers: { 'Content-Type': 'application/x-www-form-urlencoded' },
    };
    const params = new URLSearchParams();
    params.append('grant_type', 'client_credentials');
    params.append('client_id', configuration.yelpClientId);
    params.append('client_secret', configuration.yelpClientSecret);

    const { data } = await axios.post(
      YELP_AUTH_ENDPOINT,
      params.toString(),
      config,
    );

    return data;
  } catch (error) {
    console.log(error.response.data);
    return {};
  }
}

utiliser des paramètres au lieu de données

axios({
    method: 'post',
    url: '/my/api',
    headers: {
        'Content-type': 'application/x-www-form-urlencoded'
    },
    params: {
        'grant_type': 'code',
        'client_id': '1231453',
        'client_secret': 'THIS_IS_THE_SECRET'
    }
})
    .then((response) => {
        console.log(response);
    })
    .catch((error) => {
        console.log(error);
    }
);

@skuarch
utiliser des paramètres au lieu de données

Si cela fonctionne, c'est de loin la solution la plus propre.

@oshalygin , il définit les paramètres sur la chaîne de requête, n'envoie pas en tant que variables de publication.

Une bibliothèque ajax qui ne peut pas poster un formulaire simple ? Vraiment?

1

quelqu'un sait qui définir le type de contenu sur application/json.

axios.post(`${DOMAIN}${url}`,params, {'headers': {"Content-Type": "application/json;charset=UTF-8"}})

ça ne marche pas.

@hellomrbigshot probablement un problème CORS (lire à ce sujet, également dans ce fil)

Le morceau de code gênant dans Axios pour moi (avoir du mal à obtenir la bonne charge utile sans utiliser URLSearchParams) semble être

        if (utils.isURLSearchParams(data)) {
          setContentTypeIfUnset(headers, 'application/x-www-form-urlencoded;charset=utf-8');
          return data.toString();
        }
        if (utils.isObject(data)) {
          setContentTypeIfUnset(headers, 'application/json;charset=utf-8');
          return JSON.stringify(data);
        }
        return data;
      }

Donc, si data est un objet qui n'est pas un URLSearchParam (ou l'un des quelques autres types qui sont vérifiés avant cela - FormData est dans la liste et utilisé brut), alors ce sera JSON.stringified et peut entraîner la définition de l'en-tête sur application/json.
D'un autre côté, si je passe une chaîne, elle est simplement utilisée telle quelle, donc le commentaire d'adeelibr du 4 juillet est celui qui fonctionne pour moi et mes données de formulaire.

Ils doivent fournir un type d'en-tête par défaut. J'ai résolu ce problème en utilisant ce code.
c'est mon code vue + axios côté client

Vue.prototype.$http = axios;
new Vue({
    el: '#root',
    data: {
        site_url: params.site_url,
        name: '',
        description: ''
    },
    methods:{
        onSubmit(){
            var url = this.site_url + 'project/create';
            this.$http.post( url, {
                name: this.name,
                description: this.description
            } ).then(
                response => console.log(response.data)
            );
        }
    },
    mounted(){

    }
});```
Here this.$http means axios. I using axios instead of vue resource.


My Server Side Code

si ( isset( $_POST ) ) {
$fields_to_add = array( 'nom', 'description' );
$response = json_decode(file_get_contents("php://input"), true);
foreach ( $réponse comme $k => $v ) {
if( in_array($k, $fields_to_add) ){
$_POST[$k] = $v ;
}
}
echo json_encode( $_POST );
sortir();
} autre{
echo json_encode( array( 'message' => 'Requête invalide' ) );
sortir();
}
```

Mettez les noms de champs comme liste de noms de champs. Il le convertira automatiquement en message
J'espère que cela t'aides

+1

+1

+1

OMG 😱 Je ne savais pas que l' envoi d'une requête POST avec des données de formulaire application/x-www-form-urlencoded est si compliqué comme ça. Je dois relire le README plusieurs fois, et je comprends mal que le champ de données de la configuration puisse être utilisé avec qs.stringify(), ainsi que le champ params.

Pour le moment, il semble que seules les méthodes d'instance prennent en charge l'envoi de données de formulaire x-www-form-urlencoded telles que :

  • axios#post(url[, données[, config]])
  • axios#put(url[, données[, config]])
  • axios#patch(url[, données[, config]])

+1

pas résolu!

C'est ouvert comme... pour toujours. L'ancienne bibliothèque de requêtes utilisée pour le rendre si simple.

+1

+1

+1

Voici un moyen facile de le faire.
Tout d'abord, veuillez lire ici : https://github.com/axios/axios#using -applicationx-www-form-urlencoded-format

Voici un correctif :

  1. Allez sur : https://github.com/WebReflection/url-search-params

  2. Vous pouvez l'installer npm ou simplement télécharger la bibliothèque ici : https://github.com/WebReflection/url-search-params/blob/master/build/url-search-params.js

  3. Si vous avez téléchargé la bibliothèque, incluez-la simplement dans votre fichier.

//For e.g. in your index.html, 
<script src="url-search-params.js"></script>
  1. Faites ensuite une requête POST comme celle-ci :
var params = new URLSearchParams();
params.append('param1', 'value1');
params.append('param2', 'value2');
axios.post('/foo', params)
.then(function (response)
                {
                    console.log(response.data);
                })
                .catch(function (error)
                {
                    console.log(error);
                });

Cela fonctionnera comme un charme! :+1:

@aditya43 Merci !

Vous pouvez également le faire. Cela vient directement de la page axios Github. Vous devrez créer vous-même l'URL encodée, mais je viens de le tester et cela fonctionne.

axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';

Ce bug existe toujours, une mise à jour ?

@ DZuz14 Je l'essaie et ne fonctionne pas. En utilisant les axios globals, par instance, et rien.
Il semble être codé en dur.

+1

axios craint, utilisez la demande de remplacement

+1

Ça fonctionne!

https://www.npmjs.com/package/form-data-urlencoded

import getFormData from 'form-data-urlencoded';

let data = getFormData({"_csrf": 'wrwrwrvwg4657rhed4hehe4',
                            "Res1[Test1]": "segf96767", 
                            "Res2[Test2]": "hello"});
let options = {
     method: 'POST',
    headers: { 'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8' },
    url: 'http://fhfhfhfh/455454545/fhfhfhf',
    data
};

axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded;charset=UTF-8';
axios(options).then(function (response) {
              console.log(response);
    }).catch(function (error) {
             console.log(error);
        });

J'ai défini le jeu de caractères (UTF-8) dans le "Content-Type" et j'ai modifié la solution "intercepteurs" ci-dessus.
Enfin ça marche.

import axios from 'axios'
import qs from 'qs'

axios.interceptors.request.use((request) => {
  if (request.data && (request.headers['Content-Type'].indexOf('application/x-www-form-urlencoded') !== -1)) {
    request.data = qs.stringify(request.data)
  }
  return request
})

axios({
  method: 'POST',
  url,
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
  },
  data
}).then(() => {
// DO SOMETHING
})

Je n'ai trouvé que des cas cors, l'échec de l'envoi d'en-têtes de demande d'options défini un échec interdomaine, derrière l'opération ne sera pas implémentée.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

J'ai commencé avec axios, comme l'un de mes collègues me l'a recommandé, et la première tentative pour moi a été d'obtenir le jeton d'accès à partir d'une API fonctionnelle. et je me suis heurté à ce bug, puis je suis retourné à jQuery, (honnêtement, je chauffe tellement jQuery, mais il a été obligé de le faire). Je pense donc qu'il n'y a pas de meilleur moyen de faire fuir les gens de cette bibliothèque que ce vieux bug non résolu.

J'apprécie tout le travail effectué dans cette bibliothèque, en tant que développeur, je sais que créer une bibliothèque n'est pas une tâche triviale, et j'espère laisser tomber jQuery un jour et revenir ici.

@HakamFostok J'utilise avec succès github/fetch en production pour obtenir un jeton api, vous pouvez l'explorer comme alternative à jquery.
https://github.com/github/fetch

@usopan merci beaucoup, je vais y jeter un œil

@HakamFostok
Le moyen le plus simple de contourner cette erreur consiste à utiliser QS. Vous n'êtes pas obligé d'installer qs, utilisez-le directement avec qs.stringify

let qs = require('qs');
let result = await axios.post(url,
    qs.stringify({
        refresh_token: refresh_token,
        grant_type: 'refresh_token'
    }),
    {
        headers: {
            "Content-Type": "application/json"
        },
        auth: {
            username: 'username',
            password: 'secret'
        }
    });

Avec cela, vous pouvez utiliser axios qui est bien meilleur avec ES6 ;)

Mais tu as tout à fait raison. Ce bogue aurait dû être résolu il y a longtemps. Je ne sais pas ce qui leur prend si longtemps.

@HakamFostok @Silve2611 Je confirme que la solution de contournement qs fonctionne, je l'utilise pour obtenir des jetons ici : https://github.com/Halceyon/aspnet-auth/blob/master/src/AspnetAuth.js

Oui, le contournement de 'qs' fonctionne, MAIS, le problème est que je n'utilise pas 'qs' dans le projet. merci pour l'aide quand même, j'ai fini par jeter cette bibliothèque et utiliser la bibliothèque ajax https://github.com/fdaciuk/ajax c'est beaucoup mieux, et j'encourage tout le monde à débarrasser cette bibliothèque et à migrer vers là-bas.

qs est téléchargé près de 60 millions de fois par mois, il fait 4.8Kb gzippé.
Express, body-parser, request, superagent et bien d'autres en dépendent, vous pouvez l'ajouter sans crainte à votre projet.

@HakamFostok Pour autant que je sache, il fait partie du module principal, vous n'avez donc pas à l'installer manuellement si la version de votre nœud est à jour.

Je ne veux tout simplement pas installer de bibliothèque, dont je n'ai pas besoin, juste pour créer une solution de contournement pour un problème qui devrait être résolu il y a de nombreuses années. Juste pour votre information, mon projet n'est pas un projet React ni j'utilise node, j'utilise ASP.NET MVC avec vue.js

Le module "querystring" est intégré, et pour autant que je sache, il fait la même chose.

@axios Qu'en est-il de ce bug qui persiste ?

@HakamFostok J'utilise également vue et cela fonctionne vraiment parfaitement avec axios. Envisagez d'utiliser qs car axios présente de nombreux avantages si vous souhaitez utiliser l'attente asynchrone.

Le problème persiste et je dois utiliser manuellement qs comme celui-ci

axios.post(
      "connect/token",
      qs.stringify({
        username: this.state.username,
        password: this.state.password,
        grant_type: "password",
        scope: "offline_access"
      })
    );

Est-ce vraiment même un bug ? Je fais une URL encodée dans deux projets différents avec axios, et cela fonctionne très bien. Le commentaire que j'ai posté ici précédemment est la seule chose que j'ai définie, et cela fonctionne.

Bien sûr, c'est un bug ! Cela ne fonctionne pas comme décrit dans les docs. De plus, cela n'a pas de sens d'ajouter l'étape supplémentaire pour quelque chose qui devrait clairement être géré par axios. D'autres méthodes n'ont pas besoin de l'étape.

Oui, cela n'a pas de sens lorsque vous devez ajouter une étape supplémentaire.
Si je veux poster

headers: {
     'Content-type': 'application/x-www-form-urlencoded'
}

je dois écrire comme ça

axios.post(
      "connect/token",
      qs.stringify({
        username: this.state.username,
        password: this.state.password,
        grant_type: "password",
        scope: "offline_access"
      })
    );

J'ai eu le même problème en définissant Content-Type sur application/vnd.api+json , similaire à # 340, qui a malheureusement été fermé sans résolution.

Ma solution de contournement consistait à chaîner les données de l'objet afin d'envoyer le Content-Type , ce qui est un peu hacky, car nous aurions à gérer la manière axios de définir application/json;charset=utf-8 lorsqu'il s'agit d'un données d'objet.

J'espère que nous aurions plus de capacité à définir manuellement le Content-Type plutôt que de laisser axios le "deviner" pour nous.

Il devrait le "deviner" pour nous ou générer une erreur que nous pouvons gérer. Pour le moment tout va bien mais les parans ne sont évidemment pas correcf. Un débutant travaillant avec axios ne pourra pas retracer une telle erreur. Au moins, il devrait être documenté correctement.

+1 Je viens de passer 2 heures à traquer ce problème. Aurait apprécié une meilleure explication/note dans le readme à tout le moins. Mettra à jour si qs résout le problème.

MISE À JOUR : En utilisant React, qs a fonctionné pour moi. C'était ma solution. J'avais besoin à la fois de paramètres de formulaire et d'un paramètre de requête dans mon cas.

var data = qs.stringify({
    id: 'MY_ID',
    action: 'MY_DATA'
});
var params = {
  params: {
    token: 'MY_TOKEN'
  }
};
axios.post('MY_URL', data, params)
    .then(function (response) {
      console.log(response);
    })
    .catch(function (error) {
      console.log(error);
    });

J'avais besoin d'utiliser Axios avec React pour effectuer un processus de connexion et après avoir lutté pendant des heures avec ce problème, la solution consistait à créer indépendamment les objets nécessaires pour faire la demande.

L'erreur était : unsupported_grant_type

Ce travail.

import axios from 'axios';
import qs from 'qs' ;

const endPoint = `${endPointApi}/ControllerX`;  

const data = qs.stringify({ 
    grant_type: 'password',            
    user: userName, 
    password: userPass
});

const headers = {
    'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
};

axios.post(endPoint, data, headers)
.then(function (response) {
    debugger;
    console.log(response);
})
.catch(function (error) {
    debugger;
    console.log(error);
});

Cette autre façon ne fonctionne pas.

axios.post({
    url: endPoint, 
    data: data, 
    headers: {
        'Content-Type': 'application/x-www-form-urlencoded;charset=UTF-8'
    }
})...

@ harvic3 vous pouvez vérifier mon code de travail. De plus, vous n'avez pas besoin d'en-tête spécifique.

https://github.com/Awesome-CMS-Core/Awesome-CMS-Core/blob/master/src/AwesomeCMSCore/AwesomeCMSCore/React/js/App/Modules/Account/LoginForm.jsx#L40 -L79

Après 2 ans et ce bug n'est toujours pas résolu

+1

+1

+1 il y a toujours le problème

+1

+1
ping @mzabriskie @nickuraltsev

Le problème côté nodejs est que l'une des dépendances, follow-redirects , supprime l'en-tête de type de contenu :

screenshot from 2018-05-15 17-17-46
https://github.com/olalonde/follow-redirects/blob/1b6340f83ad5596a0a38c16a7113692bd90301f2/index.js#L188 -L192

+1 rencontrant définitivement le même problème ici

+1

corriger cela enfin pour ne pas utiliser les hacks comme qs (mais oui, qs fonctionne)

Hej

  1. maj 2018 23.31 skrev "Leonid Ershov" [email protected] :

corriger cela enfin pour ne pas utiliser les hacks comme qs


Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/axios/axios/issues/362#issuecomment-390337824 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AJZ-B0lPoCseiT4WNhJFlHVUTBHbmo9Yks5tzz3FgaJpZM4JAIfw
.

Il semble que ce problème ne sera pas résolu

Ça commence à devenir ridicule !

Pas même un "va te faire foutre, on ne réglera jamais ça !" :/

+1

+1

Il semble qu'un héros l'ait corrigé et ait créé une version spécifique "aaxios"
Autoriser la définition du type de contenu
Je ne l'ai pas testé cependant, je suis passé à chercher

+1

+1

+1

+1

👍
comme @camposjorge l' a dit, nous verrons peut-être un correctif (bientôt ?) grâce à https://github.com/axios/axios/pull/1544

pas de solution?

+1

résolu! ce n'est pas un problème d'axios, juste une origine croisée

set { headers : {'Content-Type' : 'application/x-www-form-urlencoded ; jeu de caractères=UTF-8'}}
et
utilisez simplement transformRequest à partir des options axios

transformRequest : [fonction (données) { format de retour (données) }],

fonction de format utilisée pour analyser {a:"a",b:"b"} en "a=a&b=b"

+1, et aucune des solutions ci-dessus n'a fonctionné

+1

Il semble que beaucoup de gens attendent toujours une solution à ce problème, moi y compris - après tout ce temps, il doit sûrement y avoir une solution proposée à ce problème.

a corrigé ce problème avec qs.stringify en réaction.

il vous suffit de qs.stringify les données avant de les passer dans axios.post

le problème est que, par défaut, le jeton CSRF est enregistré en tant qu'en-tête commun avec Axios, donc
pour résoudre ce problème

1- remplacer ces lignes dans bootstrap.js "

window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

let token = document.head.querySelector('meta[name="csrf-token"]');

si (jeton) {
window.axios.defaults.headers.common['X-CSRF-TOKEN'] = token.content;
} autre {
console.error('Jeton CSRF introuvable : https://laravel.com/docs/csrf#csrf-x-csrf-token');
}
"
par cette ligne "
window.axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';
"
2- installez le module qs par npm cliquez ici

3- définir const de qs comme ci-dessous :
const qs = require('qs');
4- utiliser axios par défaut comme ceci :
axios.post('votre lien ici ',qs.stringify({
'a1' : 'b1',
'a2 ':'b2'
}))
.alors(réponse => {

                     alert('ok');

                })
                .catch(error => alert(error));

Avec cela, j'ai pu soumettre un formulaire en utilisant axios indépendamment du fait que le type de contenu ne peut pas être modifié sur axios

```
const { nom complet, e-mail, mot de passe, téléphone } = this.state ;
axios(url, {
méthode : "POSTER",
en-têtes : {
Acceptez : "application/json",
"Content-Type": "application/x-www-form-urlencoded"
},
données : this.serialize({
nom : nom complet,
e-mail : e-mail,
mot de passe : mot de passe,
téléphone : téléphone
})
})
.alors(réponse => {
console.log(réponse);
})
.catch(erreur => {
console.log(error.response);
});

sérialiser = obj => {
soit str = [] ;
pour (laisser p dans obj)
si (obj.hasOwnProperty(p)) {
str.push(encodeURIComponent(p) + "=" + encodeURIComponent(obj[p]));
}
return str.join("&");
} ;

Cogner. Ridiculement, après des années, ce bogue ennuyeux n'est toujours pas corrigé.

Cogner. Même problème ici, correction requise af.

@mzabriskie

Cela ne devrait-il pas être fermé comme corrigé ?
Testé avec les en-têtes appropriés et ils sont correctement définis dans la requête.
En-têtes dans la demande
Définir les en-têtes ici

La bibliothèque form-urlencoded m'aide à résoudre ce problème (pour le moment).

return preset.post("/app/BookingProc.do",formurlencoded(dat),{
        headers:{
            Cookie:session
        }
    }).then(response=>{
        return response
    })

@mzabriskie

Cela ne devrait-il pas être fermé comme corrigé ?
Testé avec les en-têtes appropriés et ils sont correctement définis dans la requête.
En-têtes dans la demande
Définir les en-têtes ici

non cela ne peut pas être fermé !!!
Tout le monde se heurte au problème et ne sait pas où trouver la solution. Cela devrait fonctionner sans définir d'en-têtes ou un en-tête standard devrait être défini.
Si ce n'est pas le cas, une erreur doit être générée indiquant où se situe le problème.
De plus, la documentation doit être mise à jour.

Il est encore cassé !

Cogner. Ce bug est toujours à sa place et se sent bien!

cogner

Ce bug vit toujours !

Je rencontre également ce bug ici.

toujours dégoûtant ici

const axios = require('axios');
const qs = require('querystring');

axios.post(`${this.api}siteverify`, qs.stringify({
  secret: this.secret,
  response: recaptchaToken,
  remoteip: userIP,
}), {
  headers: {
    'Content-Type': 'application/x-www-form-urlencoded',
  },
});

Cela fonctionne pour moi. Je l'ai extrait de l'application que je développe actuellement, cette partie sert à vérifier le recaptcha de Google.

Toujours le même problème...

La configuration par défaut ne fonctionne pas :
axios.defaults.headers.common['Accept'] = 'application/json'; // working axios.defaults.headers.common['Content-Type'] = 'application/json;charset=UTF-8'; // NOT working

Et aussi la mise en demande ne fonctionne pas:
axios.get(url, { headers: { 'Content-Type': 'application/json;charset=UTF-8' } })

@aaroninn cela ne semble pas être le même problème, veuillez ouvrir un nouveau problème si vous pensez que votre problème est lié à axios (qui semble être plus lié à une utilisation de base de vuex à moi, mais je ne peux pas être sûr)

ce fil est déjà plein de +1 , pas besoin de rassembler d'autres problèmes ici

https://github.com/axios/axios/issues/362#issuecomment -229817415

@mzabriskie , il semble que vous soyez l'auteur du commit qui a introduit ce problème, vous ne pouvez rien y faire (si vous ne comprenez même pas pourquoi vous l'avez fait en premier lieu, vous pourriez/devriez l'annuler, droit?)

Merci d'avance

C'est 2018 ! Quelle réponse, ci-dessus, ne devrais-je pas voter contre ?

Redis-moi pourquoi nous aimons tous Axios ?

Ce problème a besoin d'une solution ? Ou c'est volontaire, je demande, c'est ouvert depuis 2 ans mais personne ne l'a réparé. Est-ce volontaire et n'a-t-il pas besoin d'être réparé ?

@jeremycare Je viens de créer un PR pour ce problème ... Je pense que c'est un "bug" vraiment ennuyeux et qu'il devrait être corrigé. Surtout, il est vraiment facile de résoudre ce problème et de se débarrasser de ce problème.

Les gars, je pense que je comprends pourquoi ce ticket est toujours ouvert.
Les gens qui disent que cela fonctionne pour eux utilisent maintenant le module "qs", ceux qui disent que cela ne fonctionne pas utilisent le module "querystring".
Je vois aussi des gens avoir des problèmes avec les en-têtes, ce ticket est si long pour tout lire et peut-être que je ne comprends pas tout sur le problème dans ce ticket, mais si quelqu'un ne peut pas faire de requêtes avec des données de formulaire, vérifiez ceci avant d'essayer d'autres choses :

Tout décrit ici : https://github.com/axios/axios/issues/1894

Il est décevant de voir un échange de fetch natif dans les navigateurs fonctionner instantanément avec le paramètre de Content-Type lorsqu'Axios ne parvient pas à le définir. L'interopérabilité entre les plates-formes était son principal argument de vente pour moi.

Je peux voir dans la méthode transformRequest que l'en-tête est défini mais qu'il n'arrive jamais à la demande réelle. Je ne peux pas utiliser le module qs car j'envoie simplement un corps de texte.

Pour reformuler ce que je vis : je ne peux pas définir un en-tête Content-Type dans le navigateur à l'aide d'axios car il est écrasé. J'envoie une charge utile de chaîne (pas de données de format), donc les modules qs / querystring ne sont pas pertinents pour mon cas.

Que pouvons-nous faire pour résoudre ce problème ?

EDIT: Pour l'instant, je vais juste utiliser fetch dans le navigateur, mais ce genre de nie tout l'intérêt d'utiliser axios pour moi.

EDIT2 : J'ai construit ma propre bibliothèque - capot - pour gérer mes requêtes dans plusieurs environnements (ciblant Node/Browser/React-Native). Il ne remplace en aucun cas axios et sa richesse de fonctionnalités, mais il prend en charge toutes les bases.

Vous avez le même problème. Et si je mets la clé sur autre chose, ça marche, sauf pour "Content-Type" ! S'il vous plaît aidez-moi!

J'ai en fait dû créer une autre application hybride désordonnée en utilisant fetch dans les navigateurs et axios dans node et dans react-native. C'est marrant que ce soit comme ça et non l'inverse. J'espère vraiment que cela sera bientôt résolu afin que je puisse retirer mon patch de singe.

Je pense qu'il est important de réaliser que ce n'est certainement pas seulement un problème avec querystring. Mon contenu de corps est juste du texte brut sans paramètres, mais je ne peux pas l'envoyer en utilisant axios avec un Content-Type .

J'ai essayé d'utiliser la publication, cela fonctionne bien, la valeur par défaut de la publication est json

Je rencontre ce bogue en ce moment... donc il n'y a pas de solution pour cela après des années ? Wow...

J'ai créé un PR qui résoudrait le problème il y a plus de deux mois... Je ne comprends pas pourquoi il n'est pas fusionné ? !

J'ai créé un PR qui résoudrait le problème il y a plus de deux mois... Je ne comprends pas pourquoi il n'est pas fusionné ? !

Gardez à l'esprit que personne n'a poussé quoi que ce soit depuis septembre de l'année dernière, peut-être qu'ils recherchent des mainteneurs ?. De plus, je pense que vous avez raté un test lorsque je compare votre PR avec : https://github.com/axios/axios/pull/1544/files

@mzabriskie pourriez-vous peut-être prendre la responsabilité de fusionner l'un de ces PR ? Comme actuellement, certains logiciels nécessitent que les requêtes get aient un ensemble de types de contenu (paramètres RoR par exemple : https://guides.rubyonrails.org/api_app.html#using-actiondispatch-request). La solution spécifiée dans https://github.com/axios/axios/issues/362#issuecomment -229817415 semble être la bonne voie à suivre et elle résoudrait surtout tous les hacks désespérés comme l'utilisation de fetch pour ce cas d'utilisation spécifique.

Je suis passé au pagkage got , puisque axios semble abandonné.

Axios est donc officiellement incapable d'envoyer des requêtes avec 'Content-Type': 'application/x-www-form-urlencoded' ou la solution @ChBernat fonctionne-t-elle réellement ?

Existe-t-il une solution de contournement à ce problème ?

Existe-t-il une solution de contournement à ce problème ?

Recherchez un an ici et vous verrez de nombreuses solutions de contournement ... Bien que je recommanderais, comme d'autres et moi-même inclus, de passer d'axios. C'est abandonné...

Wow... ils devraient juste abandonner le projet à ce stade, je sais que je le suis. Près de 3 ans depuis le problème signalé à l'origine et maintenant nous essayons toujours de résoudre ce problème ? Incroyable. J'adore l'open source, donc je ne nourris aucun ressentiment pour ce projet qui n'a pas de mainteneurs, mais ... il est utilisé par des TONNES de personnes, donc le moins que vous puissiez faire est de l'abandonner afin que nous sachions tous que ce projet est mort/mourant. Merci.

@justintime4tea Avez-vous une nouvelle recommandation ?

got

@kslr got or request ressemble à ce que tout le monde a commencé à migrer aussi. J'essaie de m'en tenir à Axios, mais je pense que cela finira par me revenir en écrivant une couche d'abstraction dessus afin que je puisse échanger la bibliothèque de requêtes HTTP sous-jacente, puis si j'utilise une bibliothèque différente qui a un "construit -in" client HTTP qu'il utilise, laissez-le faire son travail.

J'ai essayé quelque chose comme ça et j'ai travaillé pour moi.
Peut-être pas la meilleure solution mais cela peut vraiment aider (je pense), toute suggestion, si cette solution est horrible, est la bienvenue.

const foo= yield qs.stringify({ 'grant_type' : 'yourGrantType', 'param' : param, 'param' : param }) const bar= yield axios.post('/baz', foo)

J'ai supprimé l'en-tête et il semble qu'il ait bien été reçu.

axios({
  url,
  method: 'POST',
  headers:{
    'Content-Type': 'application/json'
  },
  data: null, // important
})

J'ai eu deux problèmes en utilisant RoR comme backend.

Mon contexte :

J'avais un projet utilisant vue-resource obsolète et tout fonctionne bien sans configuration supplémentaire. Et maintenant, j'organise les dépendances du projet et remplace les dépendances obsolètes, donc j'ai remplacé vue-resource par axios ;)...


Mais, nous avons eu quelques problèmes et ci-dessous, je partagerai ce que je fais pour résoudre ces problèmes. Peut-être aider quelqu'un ! Désolé si je ne t'ai pas aidé comme tu l'espérais

Premier problème , le problème est le même que ce problème, j'ai résolu en utilisant:

axios.interceptors.request.use(config => {
  config.paramsSerializer = params => qs.stringify(params);
  return config;
});

Maintenant, les paramètres comme :

q: {
  search: "Something",
  sort: "asc",
}

sera transformé en :
http://xxxx/?q%5Bsearch%5D=something&q%5Bsort%5D=asc

cette analyse sera :

q[search]: something
q[sort]: asc

Deuxième problème , RoR renvoie une réponse HTML au lieu d'une réponse JSON :

Ce problème se produit car notre backend doit distinguer les requêtes AJAX des autres types de requêtes.

Par défaut, vue-resource a déjà défini l'en-tête X-Requested-With comme prévu. Mais axios non. J'ai donc dû définir cette clé dans l'en-tête de la requête. Ma config globale Axios était la suivante au final :

axios.interceptors.request.use(config => {
  config.paramsSerializer = params => qs.stringify(params);
  return config;
});
axios.defaults.headers.common['Accept'] = 'application/json';
axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

===

Si vous utilisez Rails comme backend et qu'aucune des solutions n'a fonctionné pour vous, faites le moi savoir, peut-être que je vous aide =).

Je travaille sur react-native et j'obtiens une mauvaise erreur de requête 400 lors de l'utilisation de ceci :
importer * en tant que qs depuis 'querystring' ;
axios.post(url,qs.stringify({
'prenom' : 'profond',
'nom_de_famille' : 'palotra',
}),{
en-têtes : {
'Content-Type' : 'application/x-www-form-urlencoded ; jeu de caractères=UTF-8'
}
}).alors((réponse)=>{
console.log('travaillé')
}).catch((erreur)=>{
console.log('erreur')
console.log (erreur)
})

alors, comment résoudre ce problème?

Toute solution :(

Résolu par qs

{ data: qs.stringify(bodyObject) }

Triste de voir que tant de gens sont confus dans ce problème. J'ai fait de mon mieux pour lire ces commentaires. Mais il semble avoir impliqué bien d'autres problèmes.

Tout le monde, pardonnez-moi de le fermer. Si quelqu'un peut ouvrir un nouveau sujet pour décrire clairement le problème, ce sera vraiment un grand merci à vous.

Salut tout le monde,

Je pensais intervenir car j'ai perdu presque une journée de travail complète de ma vie à essayer de résoudre ce problème. Cela peut aider certains partiellement ou complètement, alors espérons que cela sera utile.

Ma réponse découle de voir diverses raisons pour lesquelles un POST échouait avec Axios, allant de :

  1. 400 Mauvaise demande
  2. Impossible de publier avec des en-têtes personnalisés (comme ce fil)
  3. Besoin de sérialiser/chaîner les données/charges utiles

J'étais confronté au même problème que tout le monde dans ce fil avec la Bad Request 400 lors de la transmission d'en-têtes personnalisés à Axios dans la configuration comme celle-ci, et j'ai essayé de nombreuses réponses ici, comme l'utilisation de qs.stringify(), la définition de données dans la configuration à null ou {} en vain.

1) Remarque - L'ajout du bloc .catch() et la journalisation de l'erreur m'ont vraiment aidé car j'ai pu faire apparaître une erreur qui n'était pas si cryptique. J'ai pu utiliser le message pour déboguer et finalement comprendre le problème que j'avais.

2) Il est important que le bloc .then() renvoie response.data , sinon vous rencontrerez cette erreur :

Converting circular structure to JSON

Maintenant, mon problème était que le corps api POST n'était pas ce que le point de terminaison voulait, mais je ne pouvais pas le voir tant que je n'étais pas en mesure d'enregistrer l'erreur.

De plus, j'utilise également NestJS et le HttpService, qui est un wrapper autour d'Axios, et cela a encore compliqué le problème car la véritable erreur ne bouillonnait pas dans le rappel catchError dans mon tube.

Voici donc la solution pour Axios pur et NestJS.

Axios :

const headers = { 'Content-Type': 'application/x-www-form-urlencoded' };
return axios.post('https://some-made-up-endpoint, dataString, { headers })
.then(resp => resp.data)
.catch(error => {
this.logger.log('ERROR: ${JSON.stringify(error.response.data)}');
});

Nest JS :

const headers = { 'Content-Type': 'application/x-www-form-urlencoded' };
return this.http.post('https://some-made-up-endpoint, dataString, { headers }).pipe(
map(response => response.data), // This is important otherwise - circular JSON error
catchError((error: any) => {
this.logger.error('[[[[ ERROR TRYING TO FETCH TOKEN: ${error.message} ]]]]');
return of()
})
).toPromise();

TLDR ;

1) Ajoutez le bloc .catch() pour enregistrer correctement la vraie erreur, sinon c'est 400 Bad Request
2) Assurez-vous que votre signature de données correspond à ce que l'API attend. Cela fait partie de la raison pour laquelle une erreur existe puisqu'un code 400 est une "Bad Request"
3) Renvoyez le response.data dans le bloc .then() si vous utilisez Axios, ou dans un opérateur de carte si vous utilisez NestJS ou vous obtiendrez l'erreur Converting circular JSON

Désolé pour le long message et bonne chance à tous !

Acclamations

Je travaille sur react-native et j'obtiens une mauvaise erreur de requête 400 lors de l'utilisation de ceci :
importer * en tant que qs depuis 'querystring' ;
axios.post(url,qs.stringify({
'prenom' : 'profond',
'nom_de_famille' : 'palotra',
}),{
en-têtes : {
'Content-Type' : 'application/x-www-form-urlencoded ; jeu de caractères=UTF-8'
}
}).alors((réponse)=>{
console.log('travaillé')
}).catch((erreur)=>{
console.log('erreur')
console.log (erreur)
})

ce travail pour moi. avec la requête stringfy merci beaucoup.
tu me sauves la vie

Vous pouvez utiliser une bibliothèque comme qs à la place :

var qs = require('qs');
axios.post('/foo', qs.stringify({ 'bar': 123 });

Votre solution fonctionne. Merci beaucoup!

Cette page vous a été utile?
0 / 5 - 0 notes