Könnten Sie ein Codebeispiel bereitstellen, das dieses Verhalten zeigt? Welchen Standardheader versuchst du aufzuheben?

Wenn ich axios.defaults.headers.common['Content-Type'] = 'application/json' setze, kann ich diesen Header für eine einzelne Anfrage nicht deaktivieren, ich kann ihn nur auf einen anderen Wert setzen.

Wie hast du versucht, den Header aufzuheben? So etwas verwenden?

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

Ja. Das hat nicht funktioniert

Entschuldigung, dass ich in meinem Beispiel das method übersehen habe. Kann es daran gelegen haben, dass es nicht funktioniert hat?

Ich habe auch versucht, die Methode einzustellen. Ich vermute, es hat irgendwo mit einem Object.assign() zu tun, das einfach nicht auf den undefined achtet.

@tyrsius welche Version von Axios verwendest du? Ich habe gerade einen Test geschrieben, um dies zu reproduzieren und er hat bestanden. Ich frage mich, ob dies möglicherweise in einer neueren Version behoben wurde.

Als Referenz hier mein 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();
  });
});

Ich hatte dieses Problem auch.
Ich versuche, den Header 'Authorization' aus 'common' zu entfernen, aber die einzige Möglichkeit, die ich gefunden habe, um es zum Laufen zu bringen, besteht darin, die Eigenschaft aus dem axios.defaults.header zu löschen, die Anfrage zu stellen und dann die Eigenschaft wieder hinzuzufügen wieder.
Dies wird einfacher, wenn dieser Fehler behoben ist

Dies ist auch ein Problem für mich (mit axios v0.14.0), insbesondere für Endpunkte, die Access-Control-Allow-Headers . In diesem Fall muss ich sicherstellen, dass bestimmte Header überhaupt nicht mit der Anfrage gesendet werden.

Ich verwende Version 15.2 und wenn ich es tue

headers: {
      'Content-Type': null
    }

es setzt den Header-Wert auf null. aber ich muss wirklich den Header-Namen vollständig entfernen.

Wenn Sie beispielsweise s3 verwenden und eine vorsignierte URL zum Posten einer Datei in einen Bucket generieren, können Sie keinen Authenticate-Header verwenden. aber ich habe eine Standard-Autorisierung eingestellt, weil die überwiegende Mehrheit meiner Anfragen dies für meine eigene API erfordert.

Ich habe das so umgangen, indem ich Folgendes getan habe:

    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: Das funktioniert nicht wie erwartet. Das Problem ist, dass wenn Sie die Kopfzeilen löschen

instance.defaults.headers.common = {};

es entfernt es auf globaler Ebene. Dadurch werde ich abgemeldet, da ich einen Header für Auth verwende.

Um dieses Problem zu umgehen, bis es eine bessere Möglichkeit gibt, die globale Konfiguration zu handhaben, übergebe ich die erforderlichen Header bei jedem Anruf, nicht ideal.

545

Ich hatte das gleiche Problem aber gelöst mit

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

Ich habe die genaue Situation als @SepiaGroup
Ich habe versucht, es mit null und '' zu überschreiben, aber dann sieht AWS null als meine Autorisierung und beschwert sich.
Ich habe versucht, es aus der Instanz zu löschen, aber dann wird meine Autorisierung global gelöscht, sodass ich 403 auf meinem eigenen Server bekomme.

Ich denke, mein Workaround wird darin bestehen, ein altes XHR dafür zu verwenden, aber es macht mich traurig:(

+1 Es ist auch nicht möglich, den Standard-Header für einen bestimmten Anruf zu löschen.

+1

+1

Ich sehe dieses Verhalten auch in der neuesten Version (0.16.2). Traurigkeit entsteht :(

einfach löschen

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})

Funktion: Abmelden () {
Instanz = axios.create({Optionen})
}
```

@lzp4ever das würde in den meisten Fällen nehme ich an. Aber in Fällen, in denen jemand Request- und Response-Interceptors hinzugefügt oder mehr Konfigurationen der Instanz vorgenommen hat, die über die einfache Übergabe von Konfigurationsoptionen hinausgehen, würde Ihr Ansatz nicht erfordern, dass all dies wiederholt wird?

Ich frage mich nur, ob die Lösung von

Wäre schön, den Standard-Header NICHT senden zu können, ohne Eigenschaften zu löschen :)

+1

+1

+1. Es scheint traurig zu sein, dass Sie die Header für eine Instanz nicht entfernen können. Das bedeutet, dass alle Instanzen eine Referenz auf die globale Variable haben.

+1

+1

+1 Bitte beheben Sie dieses Problem.

+1

+1

+1

Wir stoßen auf das gleiche Problem. Die meisten von uns erstellten Front-End-Apps müssen mehrere Rest-Webdienste nutzen. Der Sicherheitsheader kann nicht deaktiviert werden, was für uns ein großes Problem ist.

+1

+1

Probieren Sie diese Jungs an einem bestimmten Anfrageobjekt aus, zusammen mit Headern, Daten und Methode:
transformRequest(data, headers) { delete headers.common.Authorization; return data; }

Versuchen Sie dies, es löst mein Problem:

axios.defaults.headers.common["Autorisierung"] löschen; // und erstelle deine eigenen Header

@mukeshyadav Diese Lösung wurde weiter oben in diesem Thread mehrmals erwähnt.

Es wird darauf hingewiesen, dass dies nicht unbedingt die ideale Lösung ist. Stellen Sie sich ein Szenario vor, in dem Sie Ihre eigenen benutzerdefinierten Anfrage-/Antwort-Interceptors zu einer Axios-Instanz hinzugefügt haben, aber Sie möchten, dass eine bestimmte Anfrage keine Header enthält, die anderswo verwendet werden, müssen Sie die Header löschen und danach erneut hinzufügen die Anfrage ist abgeschlossen.

Umgekehrt fragen Sie sich, ob Sie relativ einfach eine Axios-Instanz duplizieren können, um sie in solchen Einzelfällen zu verwenden.

+1

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

funktioniert bei mir

@aaronatmycujoo Das scheint hier die sexieste Lösung zu sein. Fragt sich jedoch, ob das Löschen des Headers ihn aus einer Axios-Instanz weiter oben in der Kette entfernt. Möglicherweise muss eine tiefe Kopie von headers oder so erstellt werden.

Das muss ich testen.

soweit ich das beurteilen kann nicht. obwohl es einen Randfall geben könnte, den ich nicht auslöse

@SepiaGroup Sie müssen Ihren Anfragen keine Kopfzeilen hinzufügen ... Tun Sie dies:

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

Und in den Kopfzeilen der Anfrage sehen Sie nur 'application/json'

+1 danke @axelgenus deine Lösung hat funktioniert

+1

@aaronatmycujoo FTW!!! Seine Lösung funktionierte wie ein Zauber ... ty!

Beim Versuch, Dateien auf S3 hochzuladen, trat das gleiche Problem auf (nur einen Authentifizierungsmechanismus zulassen).
Habe die Lösung von
@aaronatmycujoo Diese Lösung funktioniert bei mir perfekt! 🎉
Danke Jungs, dass ihr meinen Tag gerettet habt!

+1

+1

+1

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

Funktioniert bei mir super!!!

Ich bin mir nicht sicher, ob dies allgemein bekannt ist, aber es gibt eine Reihe von "verbotenen Headern" , die nicht gelöscht werden können.

• 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

Error

TypeError: Kann nicht undefiniert oder null in ein Objekt konvertieren

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

Sie haben einen Tippfehler @putu-eka-mulyana und ich denke, dies ist der falsche Ort, um ein solches Problem zu melden.

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

+1, entferne den Zeichensatz aus dem Inhaltstyp

+1, Auth-Header für nur eine Anfrage entfernen, Anfrage-Konfigurationsobjekt aufnehmen, ohne es explizit zu löschen, indem Sie einfach einen Wert wie undefined oder null übergeben

+1, Auth-Header für nur eine Anfrage entfernen, Anfrage-Konfigurationsobjekt aufnehmen, ohne es explizit zu löschen, indem Sie einfach einen Wert wie undefined oder null übergeben

Ich habe eine OPTION-Anfrage vor meiner PUT-Anfrage, also hat die transformRequest-Lösung von

Letztendlich habe ich separate Instanzen für Authentifizierungs- und öffentliche Anfragen erstellt, sodass mein Authentifizierungsheader nur auf die Authentifizierungsinstanz angewendet wurde.

// 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 von @codeclown würde das Aufheben von Headern durch die Übergabe von null . Würde dies das Problem lösen?

@rizen PR #1845 von @codeclown würde das Aufheben von Headern durch die Übergabe von null . Würde dies das Problem lösen?

ja

Was für eine lange Reise. Hoffe #1845 wird so schnell wie möglich zusammengeführt.

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

Aus der Axios-Dokumentation:

> Dies gilt nur für die Anfragemethoden 'PUT', 'POST', 'PATCH' und 'DELETE'

Ich stoße auf eine ziemlich ähnliche Situation, aber mit einer GET-Anfrage:

1. GET http://www.saasserviceprovider.com/notpublicapi mit Header von Authorization: Bearer mytoken

1. Leitet zum AWS S3-Endpunkt um. Umleitungs-URL hat eine Abfragezeichenfolge: X-Amz-Signature=blahblahblah angehängt.

2. AWS S3 lehnt Anruf ab, weil zwei Authentifizierungen:

   • Kopfzeile: Authorization bearer token
   • Abfragezeichenfolge: X-Amz-Signature=blahblahblah

Weder transformRequest , transformResponse , axios.interceptors.request , axios.interceptors.response scheinen mir erlauben zu können, mich in den Prozess einzufügen und den Autorisierungs-Header vorübergehend zu entfernen, wenn ich auf das klicke Umleitung zu AWS S3 - vermutlich, wenn ich nach einer Umleitung einsteigen könnte, könnte ich etwas tun, um delete headers.Authorization zu bewirken.

Gleicher Aufruf mit Anforderung api/postman/etc funktioniert.

"Abhilfe":

Dies ist ein hässlicher, ineffizienter, dampfender POS... aber er "funktioniert™". Bekomme ich jetzt VC-Finanzierung?

  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
    })
  }

Aber im Ernst ... muss besser sein (innerhalb von Axios)

Ich stoße auf eine ziemlich ähnliche Situation, aber mit einer GET-Anfrage:

1. GET http://www.saasserviceprovider.com/notpublicapi mit Header von Authorization: Bearer mytoken
2. Leitet zum AWS S3-Endpunkt um. Umleitungs-URL hat eine Abfragezeichenfolge: X-Amz-Signature=blahblahblah angehängt.
3. AWS S3 lehnt Anruf ab, weil zwei Authentifizierungen:

• Kopfzeile: Authorization bearer token
• Abfragezeichenfolge: X-Amz-Signature=blahblahblah

Weder transformRequest , transformResponse , axios.interceptors.request , axios.interceptors.response scheinen mir zu erlauben, mich selbst in den Prozess einzufügen und den Autorisierungs-Header vorübergehend zu entfernen, wenn ich auf das klicke Umleitung zu AWS S3 - vermutlich, wenn ich nach einer Umleitung einsteigen könnte, könnte ich etwas tun, um delete headers.Authorization zu bewirken.

Gleicher Aufruf mit Anforderung api/postman/etc funktioniert.

Aber im Ernst ... muss besser sein (innerhalb von Axios)

@iyerusad Haben Sie einen besseren Weg als Ihren Workaround gefunden? Ich stehe vor dem gleichen Problem und es ist frustrierend, dass ich die Weiterleitung anscheinend nicht abfangen und den Authorization-Header nur für diese Folge- / Weiterleitungsanfrage (in diesem Fall an Amazon) löschen kann 🤔

@iyerusad Haben Sie einen besseren Weg als Ihren Workaround gefunden? Ich stehe vor dem gleichen Problem und es ist frustrierend, dass ich die Weiterleitung anscheinend nicht abfangen und den Authorization-Header nur für diese Folge- / Weiterleitungsanfrage (in diesem Fall an Amazon) löschen kann 🤔

Nicht wirklich - mit Option B. von unten.

_Die von mir bewerteten Optionen:_
A. Nehmen Sie einen alternativen Wrapper/Client an (zB fetch api? request? Request schien zu funktionieren, ist aber anscheinend veraltet). Dies ist möglicherweise die sauberste Option, bedeutet jedoch, dass Sie zu einer anderen HTTP-Client-Syntax wechseln.

B. Verpacken Sie meine Problemumgehung in eine Funktion und verwenden Sie diese Funktion für Anfragen, von denen ich weiß, dass sie auf dieses Problem stoßen - hässlich, scheinbar weniger effizient, aber im Moment verwendend.

C. Ich hoffe, ich bin ein Idiot und benutze Axios falsch und es gibt eine vernünftigere Problemumgehung mit Axios.

D. Axios bekommt Fix/Patch?

@mikhoq @iyerusad Würde es Ihnen etwas ausmachen , eine neue Ausgabe zu eröffnen, um Ihr Problem zu verfolgen? Denn bei der aktuellen, die vielleicht in #2844 behoben wurde, ist es anders.

Kein Problem - Geöffnet #2855.

@mikhoq Bitte fügen Sie dort einen Kommentar hinzu, wenn Sie einen öffentlichen Repro-Endpunkt haben.

Also wird transformRequest anscheinend für GET Anfragen aufgerufen? Ich habe dies versucht und es hat funktioniert, es hat nur den Header für die aktuelle Anfrage gelöscht.

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

Aber die Dokumente sagen

// transformRequest erlaubt Änderungen an den Anfragedaten bevor diese an den Server gesendet werden
// Dies gilt nur für die Request-Methoden 'PUT', 'POST', 'PATCH' und 'DELETE'

Was mich denken ließ, dass transformRequest für GET Anfragen nicht angerufen werden würde, aber das ist es. Was bedeutet diese Zeile eigentlich?

"Dies gilt nur für die Anfragemethoden 'PUT', 'POST', 'PATCH' und 'DELETE'"

Vielleicht: "Das ist potentiell nur sinnvoll für ...." ....? Es ist irreführend imo.

das funktioniert:
Überschriften: {
'Inhaltstyp': 'Anwendung/json',
'Autorisierung': null,
}

Versuchte Einstellung { headers: { 'Content-Type' = null } } ohne Erfolg,
Um @axelgenus hilfreichen Kommentar hinzuzufügen, musste ich ein bisschen weiter gehen:

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']
// ...

Der Anwendungsfall war die Implementierung der Anforderungsschicht für die Authentifizierungsmethode Bitstamp API V2 .