<p>request.get stürzt mit "Der Header-Inhalt enthält ungültige Zeichen" ab</p>

Außerdem habe ich keine Möglichkeit gefunden, diese Ausnahme abzufangen. Egal ob Try-Catch oder .on('error', ...

Ich erhalte den gleichen Fehler bei der Verwendung von Node-Version 0.12.12 und höher. Der gleiche Code funktioniert mit 0.12.9:

_http_outgoing.js:355
      throw new TypeError('The header content contains invalid characters');
            ^
TypeError: The header content contains invalid characters
    at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:355:13)
    at new ClientRequest (_http_client.js:101:14)
    at Object.exports.request (http.js:49:10)
    at Object.exports.request (https.js:136:15)
    at Request.start (//application/node_modules/request/request.js:747:30)
    at Request.end (/application/node_modules/request/request.js:1381:10)
    at end (/application/node_modules/request/request.js:575:14)
    at Immediate._onImmediate (/application/node_modules/request/request.js:589:7)
    at processImmediate [as _immediateCallback] (timers.js:367:17)

Es stellte sich heraus, dass ich in meinem Fall einen Zeilenumbruch für ein Cookie gesendet habe. Ich musste es entfernen.

Nein, mein Fall ist ein einfacher Einzeiler, keine Cookies, keine zusätzlichen Header.

Ich erhalte das gleiche Problem, wenn ich https://github.com/matt-major/do-wrapper verwende, wenn ich versuche, auf meine Kontoinformationen zuzugreifen.

_http_outgoing.js:348
    throw new TypeError('The header content contains invalid characters');
    ^

TypeError: The header content contains invalid characters
    at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:348:11)
    at new ClientRequest (_http_client.js:85:14)
    at Object.exports.request (http.js:31:10)
    at Object.exports.request (https.js:197:15)
    at Request.start (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:746:30)
    at Request.write (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:1345:10)
    at end (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:560:16)
    at Immediate._onImmediate (/home/pierre/Documents/freelance/upwork/dosh/node_modules/do-wrapper/node_modules/request/request.js:588:7)
    at processImmediate [as _immediateCallback] (timers.js:383:17)

Die Sache ist, obwohl dies einfach zu beheben ist, sollte request den Fehler abfangen und über die Fehlerbehandlungsroutinen weitergeben. Derzeit wird es als nicht abgefangene Ausnahme geworfen, die ziemlich schlimme Serverabstürze verursachen kann, von denen Sie sich nie erholen können, da Sie dies nicht manuell versuchen / abfangen können.

Ich würde also sagen, dass dies ein ziemlich schwerwiegender Fehler in request . Der Fehler muss weitergegeben werden.

Ich habe jetzt gute 2 Stunden damit verbracht, dieses Problem zu beheben, für das das Schreiben eines reproduzierbaren Testfalls ziemlich trivial war.
Ich bin zu dem Schluss gekommen, dass es mit meinem derzeitigen Wissen über die Codebasis nicht repariert werden kann, es sei denn, die Validierung würde zu https://github.com/request/caseless hinzugefügt, was mich übrigens solide 20-30 Minuten gekostet hat, um es herauszufinden self.setHeader . Dieses Verhalten ist weder auf caseless dokumentiert, noch ist aus dem Namen ersichtlich, dass es sich um das Setzen und Abrufen von Headern handelt, und es wird auch nicht erwartet, dass caseless.httpify(self, self.headers) das Objekt mit setHeader patchen würde

try/catch an dem Punkt, an dem das Anforderungsobjekt erstellt wird, ist so gut wie unmöglich wiederherzustellen, da es dann keine einfache Möglichkeit gibt, die Ausführung abzubrechen. self.req.end wird weiterhin aufgerufen, und wenn der Anruf entfernt wird, wird keines der nachfolgenden Verhalten ausgelöst (wiederum aus völlig nicht offensichtlichen Gründen).

Um es ganz klar zu sagen, es macht mir Angst, dass meine Produktionsdienste auf einer Bibliothek mit einer 1,4-k-Zeilen-Hauptdatei basieren, deren Logik so verworren ist, dass etwas so Einfaches wie das Propagieren eines Fehlers von einem Try/Catch praktisch unmöglich ist, ohne das Ganze gründlich zu studieren Rube Goldberg Ereignismaschine. Zeit, sich davon zu entfernen.

Dies betrifft auch Node 5.6.0 und höher, das eine strengere Header-Validierung hat: https://github.com/nodejs/node/blob/v5.6.0/CHANGELOG.md

Hier behoben https://github.com/request/request/pull/2164

Sehen Sie sich den Test zur Behandlung des Fehlers in Ihrem Code an.

Scheint, als ob der Fehler wie üblich mit einem .on('error', ... Ereignis behandelt wird. Gut!

Dies macht die request kugelsicherer, ohne dass die App in Zukunft bei dummen Dingen zum Absturz gebracht wird.

Nun, jetzt fühle ich mich wie ein unglaublich dummer Arsch.
Ich hatte eigentlich genau die gleiche Lösung parat und meine Tests würden ständig scheitern.
Es stellte sich heraus, dass ich in meinem "trivialen Testfall" vergessen habe, t.end() anzurufen.

Ich entschuldige mich, das nächste Mal werde ich einfach meinen Zweig veröffentlichen und um Feedback bitten.

@TimBeyer kein Problem, Version 2.71 wird mit dem Fix :+1 veröffentlicht:

@simov Die Version Postanfrage sende und Daten als Chunks erhalte.

request({
              method: 'POST',
              headers: {
                 'test': 'אבגד'
              },
              uri: apiUrl,
              qs: req.query,
              json: req.body,
              gzip: true
            }
            , function(error, response, body) {
               console.log('callback')
            })
            .on('response', function (response) {
             console.log(response)
            })
            .on('error', function (err) {
              console.log(err);
            });

Wenn ich das ausführe bekomme ich eine Fehlermeldung

return self.req.write.apply(self.req, arguments)
                 ^

TypeError: Cannot read property 'write' of undefined
    at Request.write (/Users/muhammadkhurrumqureshi/Workspace/www/node_modules/request/request.js:1385:18)
    at end (/Users/muhammadkhurrumqureshi/Workspace/www/node_modules/request/request.js:565:18)
    at Immediate._onImmediate (/Users/muhammadkhurrumqureshi/Workspace/www/node_modules/request/request.js:594:7)
    at processImmediate [as _immediateCallback] (timers.js:383:17)

Können Sie dazu freundlicherweise helfen?

@khurrumqureshi hier behoben https://github.com/request/request/pull/2165 :+1:

Im Grunde die gleiche Prüfung wie bei der Methode end . Der Grund dafür ist, dass start in der vorherigen Zeile aufgerufen wird und bis jetzt nicht erwartet wurde, dass es geworfen wird. Wenn Ihre Anfrage einen Hauptteil hat, wird write vor end aufgerufen, daher der Fehler.

@simov : +1:

Hier gilt das gleiche.

TypeError: The header content contains invalid characters
    at ClientRequest.OutgoingMessage.setHeader (_http_outgoing.js:348:11)
    at new ClientRequest (_http_client.js:85:14)
    at Object.exports.request (http.js:31:10)
    at Object.exports.request (https.js:199:15)
    at Request.start (/home/mymodule/node_modules/request/request.js:744:32)
    at Request.end (/home/mymodule/node_modules/request/request.js:1433:10)
    at end (/home/mymodule/node_modules/request/request.js:566:14)
    at Immediate.<anonymous> (/home/mymodule/node_modules/request/request.js:580:7)
    at runCallback (timers.js:570:20)
    at tryOnImmediate (timers.js:550:5)

Antwortheader sind:

headers:
      { 'x-backside-transport': 'OK OK,FAIL FAIL',
        connection: 'close',
        'transfer-encoding': 'chunked',
        'x-dp-local-file': 'true',
        'x-client-ip': '127.0.0.1,176.31.126.162',
        'x-global-transaction-id': '145630106',
        date: 'Tue, 08 Nov 2016 01:03:59 GMT',
        'www-authenticate': 'Basic realm="Gateway(Log-in)"',
        'x-archived-client-ip': '127.0.0.1',
        'content-type': '',
        'x-dp-tran-id': 'gateway' },
     rawHeaders:
      [ 'X-Backside-Transport',
        'OK OK,FAIL FAIL',
        'Connection',
        'close',
        'Transfer-Encoding',
        'chunked',
        'x-dp-local-file',
        'true',
        'X-Client-IP',
        '127.0.0.1,176.31.126.162',
        'X-Global-Transaction-ID',
        '145630106',
        'Date',
        'Tue, 08 Nov 2016 01:03:59 GMT',
        'WWW-Authenticate',
        'Basic realm="Gateway(Log-in)"',
        'X-Archived-Client-IP',
        '127.0.0.1',
        'Content-Type',
        '',
        'X-DP-Watson-Tran-ID',
        'gateway' ]

Kopfzeilen der Anfrage sind:

{ accept: 'application/json',
     authorization: 'Basic ...g==',
     referer: 'https://hostname.com/classify?text=%20So%20happy%20with%20this%20👍👍👍👍👍',
     host: 'gateway.myclass.net' }

Wie Sie sehen, enthält die Anfrage dreimal ein Sonderzeichen <U+1F44D> .

Kann es daran liegen, dass das Problem liegt?

Es sieht so aus, als ob das Modul node.js https dies nicht unterstützt.

Nur für den Fall, dass jemand anderes das gleiche Problem hatte wie ich - ich hatte diesen Fehler mit dem aws-sdk und es hat mich stundenlang verrückt gemacht. Es stellte sich heraus, dass es sich um ein PrvScan Zeichen \u001b[5~ , das aus irgendeinem Grund in meiner ~/.aws/credentials Datei lauerte, die in den Authorization-Header propagiert wurde, der von AWS-Anfragen verwendet wird. Der Fehler trat nur auf meinem Windows 7-Computer auf, es lag also wahrscheinlich daran, wie die Anmeldedatendatei von meinem AWS-Konto abgerufen wurde, und an einer Windows-Zeichencodierung. Es war auch nicht sichtbar, wenn cat die Datei mit den Anmeldeinformationen angab, wurde aber sichtbar, als ich die Datei mit vi öffnete.

Ja, hatte gerade das gleiche Problem. Ich muss zugeben, dass ich ein paar Stunden gebraucht habe, um es herauszufinden.
verwendet MINGW64 (Git Bash) auf einem Windows-Rechner. Versucht, das gleiche Skript mit Node in der Eingabeaufforderung auszuführen .... und hallo .... es hat funktioniert????

Ich bin gerade auf den gleichen Fehler gestoßen und kann keine Möglichkeit finden, ihn abzufangen. Ich baue einen Image-Proxy, damit ich nicht wirklich kontrollieren kann, was der andere Server zurückgibt. Wie kann ich das Carshing des gesamten Servers in der Produktion vermeiden?!

Ich hatte das gleiche Problem, es begann zu funktionieren, als ich das "set" gegen "auth" austauschte. Zum Beispiel:

it('ERROR, Wrong GET request', (done)=>{
    request(server).get("/api/")
    .set('Authorization', 'Bearer ' + tokenKey)
    .then(res=>{
        expect(res.statusCode).to.equal(404);
        done()
    }).catch(err=>done(err))
})

CONSOLE RES: FEHLER, Falsche GET-Anfrage:
TypeError [ERR_INVALID_CHAR]: Ungültiges Zeichen im Header-Inhalt ["Autorisierung"]

Nachdem Sie den Code geändert haben in:

it('ERROR, Wrong GET request', (done)=>{
    request(server).get("/api/")
    .auth('Authorization', 'Bearer ' + tokenKey) //**<---here is the change**
    .then(res=>{
        expect(res.statusCode).to.equal(404);
        done()
    }).catch(err=>done(err))
})

KONSOLE RES: OKI ;p