Axios: Application d'envoi PUT et PATCH/données codées x-www-form-urlen

J'ai essayé d'utiliser formData mais cela est toujours envoyé comme une balise body dans chrome et non comme formData.

En-têtes

PUT /url/path HTTP/1.1
Host: hostname
Connection: keep-alive
Content-Length: 1234
User-Agent: Mozilla/5.0 
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryJsCvT2m1SBzbA23B
Accept: application/json, text/plain, */*
Referer: URL
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

Charge utile

Content-Disposition: form-data; name="firstname"

Daniel
------WebKitFormBoundaryJsCvT2m1SBzbA23B
Content-Disposition: form-data; name="surname"

Persson

À la place de

En-têtes

PUT /url/path HTTP/1.1
Host: hostname
Connection: keep-alive
Content-Length: 1234
Accept: */*
Origin: http://adminhost
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: URL
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

Données de formulaire

firstname=Daniel&surname=Persson

Si cela ne devrait pas être standard, je pense que cela devrait au moins être une option à envoyer en tant que données de formulaire.

J'ai fait un petit travail pour résoudre le problème pour moi.

      config['transformRequest'] = [function (data, headers) {
        var str = [];
        for(var p in data)
          if (data.hasOwnProperty(p) && data[p]) {
            str.push(encodeURIComponent(p) + "=" + encodeURIComponent(data[p]));
          }
        return str.join("&");
      }];

J'ai rencontré cela aussi, merci pour la solution de contournement :+1:

@kalaspuffar sommes-nous d'accord pour fermer ça ?

@mzabriskie

Salut.

Je ne travaille actuellement pas sur le projet en utilisant axios, donc je ne peux pas vérifier si la nouvelle version résout le problème, mais la solution de contournement fonctionne bien pour nous pour le moment.

Si le problème est résolu, fermez. Si ce n'est pas le cas, documentez peut-être une solution de contournement afin que les autres n'aient pas à rechercher ce message.

Mais ça ne me dérange pas de fermer le sujet.

Meilleures salutations
Daniel

Que diriez-vous d'axios incluant le code de sérialisation mentionné ci-dessus afin qu'un Content-Type de application/x-www-form-urlencoded déclenche le bon encodage lorsqu'un objet est passé ?

axios.post(
  '/foo',
  { some: 'data' },
  { headers: { 'Content-Type': 'application/x-www-form-urlencoded' } }
);

… devrait fonctionner hors de la boîte IMHO. Ou est-ce que je rate quelque chose ?

:+1 : pour prendre en charge x-www-form-urlencoded lorsque les en-têtes sont définis

+1

Juste un peu d'art antérieur à ajouter ici. La bibliothèque de requêtes utilise différentes clés pour body , form (urlencodé, ce dont nous parlons ici) et formData (téléchargements de formulaires en plusieurs parties). Cela oblige l'utilisateur à savoir que ceux-ci doivent être différents et à faire un choix. J'aimerais qu'axios choisisse simplement une valeur par défaut raisonnable basée sur le type de contenu, mais cela pourrait être un changement radical si quelqu'un s'appuie sur l'ancienne implémentation.

@jimthedev Vous avez peut-être raison d'avoir choisi le mauvais type d'objet de données.

Mais ce que j'ai trouvé étrange, c'est qu'un simple GET et POST me donnaient des informations de formulaire simples dans la requête

?ab=CD&ef=gh

en utilisant l'envoi par défaut. Mais PUT et PATCH ont changé la valeur par défaut en données multiparties.

@kalaspuffar Oh je vois. Ouais ça semble étrange.

+1 x-www-formulaire-urlencodé

Agréable

y a-t-il un intérêt à avoir un support de première classe pour le put/post urlencodé intégré dans axios ?

Oui

+1

+1

+1

+1

+1

Je pense que cela devrait être résolu en ajoutant la prise en charge de URLSearchParams . BTW, cela a récemment été implémenté dans fetch : https://github.com/github/fetch/commit/d77810a15c78bbbaf2defd4ea3af6db21c8d117f

Le seul problème est que URLSearchParams n'est pas pris en charge par tous les navigateurs, mais il existe un polyfill.

+1

Content de voir que c'est en cours

axios v0.12.0 prend en charge URLSearchParams qui peut être utilisé pour envoyer les données en tant qu'application/x-www-form-urlencodé depuis le navigateur :

var params = new URLSearchParams();
params.append('param1', 'value1');
params.append('param2', 'value2');
axios.post('/foo', params); 

Veuillez noter que URLSearchParams n'est pas pris en charge par tous les navigateurs, vous devrez donc peut-être le remplir . (Assurez-vous d'ajouter le polyfill à la portée globale.)

+1 J'en ai vraiment besoin aussi, ce serait formidable si le "urlencodé" pouvait fonctionner à partir d'AXIOS uniquement en fonction du type de contenu.

+1 Il devrait être géré par la bibliothèque. Les paramètres de données doivent être simplement des objets et nous ne voulons pas nous soucier du type de requête dont il s'agit.

+1 a toujours des problèmes avec ça.

+1
J'ai utilisé le polyfill URLSearchParams recommandé. Semble toujours avoir le problème lors de l'utilisation d'IE11.

Éditer:
Le problème a été causé par le clonage de l'objet de configuration axios avant qu'il ne soit transmis à axios pour demande. Si l'objet de configuration contient une instance de URLSearchParams pour les données dans IE11 à l'aide du Polyfill recommandé, l'instance de URLSearchParams dans l'objet cloné n'est pas clonée correctement. Ce n'est tout simplement plus une instance URLSearchParams.

@kalaspuffar amélioration de votre fonction pour analyser également les objets
axios.post(url, { user: { name: 'john' }}, ...) sera encodé comme user[name] = john

function jsonToFormEncoded(data, headers) {
  var str = [];
  for(var p in data){
    if(_.isObject(data[p])){
      var d = data[p];
      for(var o in d){
        if (d.hasOwnProperty(o) && d[o]) {
          str.push(p+'['+encodeURIComponent(o) + "]=" + encodeURIComponent(d[o]));
        }
      }
    }else{
      if (data.hasOwnProperty(p) && data[p]) {
        str.push(encodeURIComponent(p) + "=" + encodeURIComponent(data[p]));
      }
    }
  }
  return str.join("&");
}

Ayant le même problème. En utilisant le middleware OWIN et puisque la requête axios.put envoie du JSON brut, je ne peux pas le gérer correctement.

Toujours des problèmes. Surpris qu'il n'ait pas été corrigé depuis qu'il s'agit d'une fonctionnalité si essentielle ?

+1

Ce truc est vraiment ennuyeux. Avoir à installer un polyfill semble tout simplement trop, Axios devrait s'en occuper de manière transparente. De tels problèmes incitent les gens à rechercher d'autres bibliothèques à la place.

J'utilise cet intercepteur, qui fonctionne assez bien.

Vue.axios.interceptors.request.use((config) => {
    if (config.headers['Content-Type'] && config.headers['Content-Type'] === 'application/x-www-form-urlencoded') {
      config.transformRequest = (data) => {
        const str = [];
        Object.keys(data).forEach(key => str.push(`${encodeURIComponent(key)}=${encodeURIComponent(data[key])}`));
        return str.join('&');
      };
    }

    return config;
  }, error => Promise.reject(error));

@kalaspuffar -s code comme configuration par défaut, merci ça marche maintenant !

```

axios.defaults.headers.post['Content-Type'] = 'application/x-www-form-urlencoded';
axios.defaults.transformRequest = [fonction (données, en-têtes) {
var chaîne = [] ;
pour (var p dans les données)
if (data.hasOwnProperty(p) && data[p]) {
str.push(encodeURIComponent(p) + "=" + encodeURIComponent(data[p]));
}
return str.join("&");
}] ;

Un an plus tard et c'est toujours un problème. (Et pourquoi est-il fermé ?)

Même URLSearchParams ne couvre pas tout le problème.

Maintenant, je veux envoyer un objet FormData, par PATCH. Et que dois-je faire ?

jQuery l'a sorti de la boîte il y a de nombreuses années. Mais axios ne peut pas reconnaître formData