Request: Erreur : le socket raccroche

J'ai le même problème, mais ajouter l'option gzip:true fonctionnera.

Quelle version de node.js utilisez-vous ? Nous voyons occasionnellement des exceptions ECONNRESET après la mise à niveau de 0,10 à 0,12. En fouillant dans les bogues node.js, il semble que cela ait pu être cassé en 0.12 et corrigé par la suite.

Même problème ici. Les mises à jour ? J'utilise node.js 4.2.2 et j'obtiens une erreur ECONNRESET périodique (3-4 fois par minute).

Salut @aymeba, il semble que la première version 4.x qui a ce correctif soit la 4.4.0.

Recherchez les commits intitulés http: handle errors on idle sockets . Il y a un tas de commits différents avec ce titre, car il a été appliqué à différentes branches.

Peu importe, je me suis trompé et je parlais d'un bogue ECONNRESET dans node.js (#3595).

Je ne pense pas que cela arrive à cause du bug que vous avez signalé. Dans notre cas, il apparaît :

• Envoyez une demande à notre backend
• Le backend traite la demande
• D'une manière ou d'une autre, la demande se déconnecte sans attendre la réponse et nous obtenons ECONNRESET
• Nous sommes sûrs que notre serveur principal ne rompt pas la connexion

Je suis confus pour obtenir cette erreur car dans un cas habituel, notre serveur principal devrait lancer cette erreur ou ?

Une mise à jour à ce sujet ?. Je vois l'erreur avec le botkit 0.2.1.

J'ai un problème similaire. J'ai fait des heures de recherche, de test et de débogage. Dans mon cas, poster sur le même restapi via Postman, le point final fonctionne bien. Échec de la demande via l'appel natif NodeJS http.request. Tous les en-têtes et la charge utile (corps) sont les mêmes. (sauf que je n'ai pas le jeton du facteur dans les en-têtes)

Divulgation complète, j'utilise restify pour mon serveur.

Si vous utilisez restify côté serveur, il serait utile d'activer l'auditeur, ce qui devrait fournir des indications sur ce qui se passe. Assurez-vous également que vous définissez le bon "Type de contenu" dans votre demande afin que le serveur sache à quoi s'attendre. J'ai vu cette erreur lorsque le serveur comprend mal la demande, donc fournir le type de contenu aidera.

Une mise à jour sur ce problème? Je vois toujours ce problème se produire avec Node v5.0.0. Je vois qu'il génère une erreur exactement 45 secondes après le moment où la demande est faite.

J'ai vu ce même problème avec HapiJS. Le problème était un en-tête de longueur de contenu incorrect

je souhaite faire une demande d'abonnement et de notification merci...

se passe avec Node v6.9.2.

  get: async function(ctx) {
    let body = await new Promise(function(resolve, reject) {
      return ctx.req.pipe(request('/path/to/my/backend', function(err, res, body) {
        if (err) { return reject(err) }
        resolve(body)
      }))
    })
    return body
  }

Je vois cela aussi avec le nœud 6.6.0. Le serveur auquel je me connecte n'envoie pas d'en-tête Content-Length dans la réponse, auquel cas, selon la spécification HTTP, le serveur doit fermer le flux après avoir envoyé toutes les données. Je soupçonne que cela est mal interprété comme un raccrochage de socket. Faire la même demande avec cURL fonctionne très bien.

+1
Nœud 6.9.4
demande 2.79.0

Fonctionne bien avec curl
L'url que j'essaie d'obtenir renvoie l'en-tête Content-Length

+1
Nœud 6.9.1
demande 2.79.0

Wget, curl - succès, mais demande - erreur.

Nœud - v6.9.4
Demande - 2.79.0

# node req.js
REQUEST { uri: 'http://wtfismyip.com', callback: [Function] }
REQUEST make request http://wtfismyip.com/

{ Error: socket hang up
    at createHangUpError (_http_client.js:254:15)
    at Socket.socketOnEnd (_http_client.js:346:23)
    at emitNone (events.js:91:20)
    at Socket.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9) code: 'ECONNRESET' }

Avoir le même problème. Il est intéressant de noter qu'il semble être indépendant de la version de la demande car le même code fonctionne pour moi dans 6.4.0, mais s'arrête dans 6.9.2 (ce ne sont que les 2 versions de nodejs que j'ai installées).

Dans mon cas, j'ai pu contourner le problème en définissant l'en-tête Connection: keep-alive .

@dieseldjango Merci pour la suggestion. N'a pas résolu mon cas cependant.

Voici un site qui donne cette erreur, pour reproduction :

{ request: 
   { debugId: 1,
     uri: 'https://www.deal.no/',
     method: 'GET',
     headers: 
      { Connection: 'keep-alive',
        host: 'www.deal.no',
        'accept-encoding': 'gzip, deflate' } } }
error:  Error: socket hang up
    at TLSSocket.onHangUp (_tls_wrap.js:1111:19)
    at TLSSocket.g (events.js:291:16)
    at emitNone (events.js:91:20)
    at TLSSocket.emit (events.js:185:7)
    at endReadableNT (_stream_readable.js:974:12)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)

..en utilisant request-debug pour déboguer les en-têtes envoyés

N'est-ce pas encore résolu ? Cela fonctionnait bien comme il y a deux semaines et j'obtiens maintenant cette erreur
{ [Error: socket hang up] code: 'ECONNRESET', response: undefined }
nœud -v 4.4.7

essayez de supprimer 'accept-encoding': 'gzip, deflate' dans les en-têtes a résolu ce problème.

Je vois que les gens obtiennent cette erreur plus fréquemment. Dans mon cas, c'était vraiment simple. Ce que j'étais bien une URL correctement formée basée sur un de mes algorithmes, était en fait malformés. J'encourage tous ceux qui rencontrent ce problème à supposer que le problème est dans votre code. Je vous assure que dans 98% des cas, la cause première est quelque chose de banal que vous tenez pour acquis ou que vous négligez. J'ai essayé tout ce qui précède pour résoudre le problème, mais à la fin, cela s'est réduit à une barre oblique supplémentaire.

J'essaie de suivre tout ce que vous dites, mais ce problème persiste. si triste....

Si cela aide quelqu'un, j'ai finalement contourné le problème en utilisant require('child_process').exec pour appeler curl. Assurez-vous de désinfecter correctement vos entrées si elles proviennent de l'espace utilisateur.

Veuillez essayer de demander à google.com => nom d'hôte : 'google.com' pour vérifier que cela fonctionne ou non.
Dans mon cas, "nom d'hôte" a été géré par nginx en tant que proxy et il ne répond pas lorsqu'il reçoit une demande avec un corps vide.
Ce code obtient une erreur :

var http = require("http");
var options = {
  hostname: 'myAddressNginx',
  port: 80,
  path: '/',
  method: 'GET',
  headers: {
    'Content-Type': 'text/html',
    'Content-Length': Buffer.byteLength("")
  }
};

var req = http.request(options, (res) => {
  res.on('data', (chunk) => {console.log("%s", chunk);});
  res.on('end', () => {});
});

// write data to request body
req.write("");
req.end();

Ce code fonctionne

var http = require("http");
var options = {
  hostname: 'myAddressNginx',
  port: 80,
  path: '/',
  method: 'GET',
  headers: {
    'Content-Type': 'text/html',
    'Content-Length': Buffer.byteLength("")
  }
};

var req = http.request(options, (res) => {
  res.on('data', (chunk) => {console.log("%s", chunk);});
  res.on('end', () => {});
});

// write data to request body
req.write("abc");
req.end();

+1
Nœud 6.9.5

Salut les gars, j'ai le même problème. +1
Heureusement, j'utilise 'request' dans un deuxième outil de surveillance, mes problèmes sont donc minimes. J'aime beaucoup node.js, donc je poste quelques commentaires. J'espère que mes commentaires vous aideront un peu dans vos tentatives de résoudre le problème.

L'erreur apparaît désormais de manière cohérente dans les environnements de production à fort trafic.
Je peux faire tourner une réplique "exacte" du serveur et l'erreur "jamais" apparaît. Je peux changer de point de terminaison, et cela finit toujours par entraîner cette erreur pour le client dans l'environnement de production à fort trafic.
{ [Erreur : socket raccrocher] code : 'ECONNRESET' }.

Cela a commencé comme une erreur intermittente que j'ai remarquée il y a plusieurs jours et après que le service de surveillance ait déclenché de fausses alarmes trop de fois... recherche sur le Web pour trouver ce problème ici.

Maintenant, je n'ai modifié aucun code/version depuis plus de 8 mois pour cette application et je ne comprends pas comment cela peut se produire de nulle part. Alors... qu'est-ce qui a changé dans le monde des « requêtes » si je n'ai modifié aucun code client ?

+1
Nœud 6.9.1

Cela ne se produit que de temps en temps, lorsque je teste mes points de terminaison localement, en exécutant de nombreuses requêtes de manière assez rapide...

Nous sommes également confrontés au même problème avec node4 et node6. fonctionne bien avec node0.12.

S'il vous plaît aider à résoudre ce problème.

question similaire natif https.request question
voir plus ici ,

ajouter ci-dessous pour demander l'option contournera (réparera) ce problème,

agentOptions: {
  ciphers: 'DES-CBC3-SHA'
}

Je me suis rattrapé et j'ai passé tout l'après-midi à essayer de comprendre... j'étais dans un environnement compliqué avec plusieurs couches de redirection : is this DNS issue? -> no way it's DNS -> definitely DNS -> no it's not
jusqu'à ce que je voie l'exemple de

Pas de chance.

mettre les chiffrements à la suite n'a pas fonctionné pour moi.
Options de l'agent : {
chiffrements : 'DES-CBC3-SHA'
}

@aganapan quelle est l'URL que vous

J'ai eu le même problème. J'ai utilisé ngrok et regardé la demande RAW. Il s'est avéré qu'il y avait un caractère e2808b non imprimable ajouté à l'entrée de l'utilisateur. Très probablement copier/coller. J'ai utilisé encodeURIComponent() sur la partie URI fournie par l'utilisateur et le problème a disparu.

J'ai eu le même problème.

• nœud V6.9.5
• demande V2.69.0

@danielkhan J'ai utilisé la méthode encodeURIComponent ;

// this is request
{
    "request": {
        "debugId": 5,
        "uri": "https://xxx.cdn.cn/js/information_main_27d1838a.js",
        "method": "GET",
        "headers": {
            "user-agent": "Mozilla/5.0 (Linux; Android 5.1.1; Nexus 6 Build/LYZ28E) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Mobile Safari/537.36",
            "host": "xxx.cdn.cn"
        }
    }
}

{
    "response": {
        "debugId": 5,
        "headers": {
            "expires": "Sat, 15 Apr 2017 11:01:16 GMT",
            "date": "Thu, 16 Mar 2017 11:01:16 GMT",
            "content-type": "application/x-javascript; charset=utf-8",
            "content-length": "49785",
            "last-modified": "Sun, 12 Mar 2017 14:30:49 GMT",
            "cache-control": "max-age=2592000",
            "access-control-allow-origin": "*",
            "accept-ranges": "bytes",
            "age": "19",
            "x-cache": "HIT from www.matocloud.com",
            "connection": "close",
            "alt-svc": "h2=\":443\""
        },
        "statusCode": 200
    }
}

Node.js 6.10.0
demande 2.72.0

Nous avons rencontré le même problème lors de l'exécution de certains tests d'intégration backend. Notre produit se connecte à plusieurs périphériques réseau via HTTPS. Dans ce scénario, nous établissons plusieurs connexions HTTPS et exécutons des requêtes POST et GET sur chaque appareil.
Étant donné que le problème s'est produit dans notre environnement de test, la solution de contournement consistait à désactiver les connexions persistantes HTTP (définissez l'en-tête HTTP Connection: close ). En faisant cela, nous demandons au serveur de fermer la connexion après avoir fourni la réponse (HTTP/1.1). Cependant, nous perdons les avantages des connexions HTTP persistantes puisque désormais chaque TCP ne servira qu'une seule requête.

chrome bloque cette solution DES-CBC3-SHA

Pour moi, curl ne fonctionne pas. J'ai découvert que j'avais déjà défini un proxy sur mon outil de ligne de commande. Cela fonctionne bien maintenant lorsque je supprime le proxy.

J'ai toujours ce problème.

{ Error: socket hang up
 at createHangUpError (_http_client.js:302:15)
 at Socket.socketOnEnd (_http_client.js:394:23)
 at emitNone (events.js:91:20)
 at Socket.emit (events.js:186:7)
 at endReadableNT (_stream_readable.js:974:12)
 at _combinedTickCallback (internal/process/next_tick.js:74:11)
 at process._tickDomainCallback (internal/process/next_tick.js:122:9) code: 'ECONNRESET' }

J'ai enfin réussi à faire fonctionner cela pour le recaptcha. J'ai dû importer et utiliser la bibliothèque https. Voici le code de travail :

var https = require('https');
var querystring = require('querystring');

var secret = "VOTRE_CLE";
var réponse = RESPONSE_CODE ;
var postData = "secret="+secret+"&"+"réponse="+réponse ;

// Construire la chaîne de publication à partir d'un objet
var post_data = querystring.stringify({
'niveau_compilation' : 'OPTIMISATIONS_AVANCEES',
'output_format' : 'json',
'output_info' : 'compiled_code',
'warning_level' : 'CALME',
'js_code' : postData
});

var options = {
nom d'hôte : « www.google.com »,
port : 443,
chemin : '/recaptcha/api/siteverify',
méthode : 'POSTER',
en-têtes : {
« Type de contenu » : « application/x-www-form-urlencoded »
//'content-encoding': 'gzip',
//'Connexion': 'fermer'
},
Options de l'agent : {
chiffrements : 'DES-CBC3-SHA'
}
} ;
var req = https.request(options, function(res) {
console.log('Status : ' + res.statusCode);
console.log('En-têtes : ' + JSON.stringify(res.headers));
res.setEncoding('utf8');
res.on('données', fonction (corps) {
console.log('Corps : ' + corps);
});
});
req.on('erreur', fonction(e) {
console.log('problème avec la requête : ' + e.message);
});
// écrire les données dans le corps de la requête
req.write(postData);
req.end();

REMARQUE : enregistrez-le pour les autres qui tomberont probablement sur cette discussion lors de la recherche sur Internet de ce message d'erreur particulier.

Il s'avère que la plupart de la discussion ci-dessus manque le point, car l'erreur n'est pas causée par le site client et donc essayer différentes "solutions de contournement" pour request ne fonctionnera probablement pas. Le problème est que le socket de requête HTTP côté serveur atteint le délai d'inactivité, en raison d'un long délai dans une opération en arrière-plan, puis ferme le socket. Cela se traduit par l'ECONNRESET côté client.

Si vous êtes également responsable du code source côté serveur et utilisez le framework express/koa, vous devez désactiver le délai d'inactivité sur le socket de requête HTTP avant de lancer l'opération backend de longue durée. Par exemple pour un gestionnaire de route koa ES6 :

javascript ctx => { .... ctx.socket.setTimeout(0); // now trigger the long lasting backend operation .... }

Maintenant, mon problème de délai d'attente client a disparu sans changer aucune ligne dans le code client...

assurez-vous que vous appelez l'URL avec le bon SSL - https ou http

C'est aussi un problème de proxy dans mon cas. Après avoir réinitialisé http_proxy et https_proxy, le problème a disparu.

J'ai eu le même problème.

Pour la boucle :
HTTP/1.1 200 OK

Pour le module http natif :
{ [Error: socket hang up] code: 'ECONNRESET' }

Pour le module de demande :
{ [Error: socket hang up] code: 'ECONNRESET' }

La raison était en réponse, en particulier dans la mauvaise syntaxe du protocole http.
\n symbole \r\n , et après le dernier en-tête - \r\n\r\n .

Quand il a été corrigé, l'erreur a disparu.

Peut-être que cela sera utile et fera gagner du temps à quelqu'un.

J'ai eu le même problème. Dans mon cas, j'ai défini User-Agent dans les en-têtes des options de demande et le problème a disparu.

Même problème avec Node 8.x

+1
Nœud 8.1.2
"requête": "=2.81.0"

{
    "method": "GET",
    "json": true,
    "uri": "http://www.bb.com/xxxxxxxxxxx",
    "baseUrl": null,
    "headers": {
        "cookie": "yyyyy",
        "user-agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_3 like Mac OS X) AppleWebKit/603.3.8 (KHTML, like Gecko) Mobile/14G60"
    },
    "qs": {
        "app_version": "1.9.8.8",
        "env": "prod"
    }
}

//res
Error: socket hang up
InternalServerError: Internal Server Error

// setting
var _request = require('request').defaults({
        forever      : true,
        maxRedirects : 8
    }),

J'ai la même erreur, mais un peu différente, ma situation est la suivante.
testapp -> api A -> api B
-> signifie demande
L'application de test obtient l'erreur de raccrochage lorsque A demande B très lentement et obtient finalement une erreur 500 de B (l'erreur est gérée dans l'api A).
Je suis sûr que ce n'est pas un problème de délai d'attente, car l'API A fait beaucoup de choses et renvoie toujours une réponse très lente, mais pas d'erreur.
Maintenant, je ne comprends vraiment pas comment fonctionnent l'express et la demande, l'erreur 500 est déjà gérée par l'api A et d'autres actions sont suivies. pourquoi l'application de test obtiendra-t-elle toujours une erreur de raccrochage du socket ?

Je rencontre également ce problème dans le dernier nœud (8.6) ainsi qu'avec la dernière version 7.x. Les détails sont ici si quelqu'un veut essayer : https://stackoverflow.com/questions/46666079/node-js-http-get-econnreset-error-on-read

S'il vous plaît laissez-moi savoir si je peux fournir des informations supplémentaires!

Avoir le même problème avec le nœud 6.10.0

Autre explication possible : vous envoyez plus de données dans le corps HTTP que spécifié dans l'en-tête Content-Length

+1
Nœud 8.6.0

Pour résoudre le problème, vous devez :
1-Ajouter process.env.NODE_TLS_REJECT_UNAUTHORIZED = "0" ;
2-Mettre à niveau zone.js vers la v0.7.4

J'ai eu le même problème et la résolution consistait à utiliser la variable d'environnement NO_PROXY="yourcompany.com" ainsi que strictSSL:false , car notre demande était adressée à l'URL interne de l'entreprise et tentait d'utiliser un serveur proxy. Vous pouvez utiliser process.env.NO_PROXY="votreentreprise.com" par programmation.

+1
Nœud 8.8.1

at createHangUpError (_http_client.js:329:15)
at Socket.socketOnEnd (_http_client.js:421:23)
at emitNone (events.js:110:20)
at Socket.emit (events.js:207:7)
at endReadableNT (_stream_readable.js:1056:12)
at _combinedTickCallback (internal/process/next_tick.js:138:11)
at process._tickDomainCallback (internal/process/next_tick.js:218:9) code: 'ECONNRESET' }

Il semble que le problème de mon côté était que Vagrant "occupait" le port et envoyait un paquet TCP avec un indicateur FIN immédiatement après ma demande GET bien que l'on ne sache toujours pas pourquoi chrome et le facteur n'ont eu aucun problème travailler autour de cela - ils ont peut-être une résilience supplémentaire

J'ai eu ce problème, GZIP était activé, Keep Alive était également activé.
Le problème a disparu après l'ajout de packages.

const zlib = require('zlib'); // for GZIP
const http = require('http');
const https = require('https');

Même problème - résolu en changeant l'URL de localhost à l'adresse IP réelle de la machine hôte juste un FYI

Toujours avec ce problème... Aucune raison apparente.

info:  Error: socket hang up
    at createHangUpError (_http_client.js:345:15)
    at Socket.socketOnEnd (_http_client.js:437:23)
    at emitNone (events.js:110:20)
    at Socket.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1059:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

salut， je ne sais pas si vous avez encore résolu ce problème， mais j'avais résolu ce tody, quand je débogue, je trouve,

// Using native http
let postData = querystring.stringify(data);
...
req.write(postData);

si votre serveur distant est démarré par koa (ou un autre serveur nodejs), et que les données sont {} , la fonction postData by stringify se transforme en {} , mais le serveur koa obtient le {} lancera le parser error , donc cette requête lancera une erreur par

Error: socket hang up
    at createHangUpError (_http_client.js:345:15)
    at Socket.socketOnEnd (_http_client.js:437:23)
    at emitNone (events.js:110:20)
    at Socket.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1059:12)
    at _combinedTickCallback (internal/process/next_tick.js:138:11)
    at process._tickDomainCallback (internal/process/next_tick.js:218:9)

donc j'ai dû faire ceci : __postData = postData === '{}' ? '' : postData__

j'espère que ça pourra t'aider

Pour moi, cela se produit lors de l'envoi d'une requête POST avec content-length : 0 dans les en-têtes de requête. Je ne sais pas si ce résultat est raisonnable, mais au moins je pense que vous pouvez peut-être essayer de supprimer chaque élément dans les en-têtes que vous avez ajoutés pour découvrir la raison du problème.

quand je change « GET » en « POST », corrigez-le. mais je ne sais pas pourquoi, je le répare à partir de https://cnodejs.org/topic/57a6c35282e6ea4870ecd3f2 , quelqu'un a dit que si vous utilisez 'GET', le code ne peut pas exécuter res.on('data', cb)

@LvChengbin J'étais également confronté au même problème sur la demande POST . Remplacer Content-Length : 0 par la longueur réelle du corps a fonctionné pour moi.

Que quelqu'un me sauve :ange:

J'ai aussi le même problème dans Bode v.8.9

{ Erreur : le socket raccroche
à createHangUpError (_http_client.js:331:15)
à Socket.socketOnEnd (_http_client.js:423:23)
à l'émissionNone (events.js:111:20)
à Socket.emit (events.js:208:7)
à endReadableNT (_stream_readable.js:1064:12)
à _combinedTickCallback (interne/process/next_tick.js:138:11)
à process._tickCallback (interne/process/next_tick.js:180:9) code : 'ECONNR
ESET' }

mon code est ci-dessous.

let request=require("request");
demande({
URL : " http://192.168.31.29 :3019/tactics/createMediaHotTotal20",
méthode : " GET ",
json : vrai,
en-têtes : {
"content-type": "application/json"
},
}, fonction (erreur, réponse, corps) {
si (erreur) {
console.log(erreur)
} autre {
résoudre (corps);
}
})

Même problème, nœud v9.5.0

const https = require("https");
const fs = require("fs");

process.env.NO_PROXY="yourcompany.com";

const options = {
  hostname: "en.wikipedia.org",
  port: 443,
  path: "/wiki/George_Washingtons",
  method: "POST",
  // ciphers: 'DES-CBC3-SHA'
};

const req = https.request(options, (res) => {
  let responseBody = "";
  console.log("Response started");
  console.log(`Server Status: ${res.statusCode} `);
  console.log(res.headers);
  res.setEncoding("UTF-8");

  res.once("data", (chunk) => {
    console.log(chunk);
  });

  res.on("data", (chunk) => {
    console.log(`--chunk-- ${chunk.length}`);
    responseBody += chunk;
  });

  res.on("end", () => {
    fs.writeFile("gw.html", responseBody, (err) => {
      if (err) throw err;
      console.log("Downloaded file");
    });
  });
});

req.on("error", (err) => {
  console.log("Request problem", err);
});

Request problem { Error: socket hang up
    at createHangUpError (_http_client.js:330:15)
    at TLSSocket.socketOnEnd (_http_client.js:423:23)
    at TLSSocket.emit (events.js:165:20)
    at endReadableNT (_stream_readable.js:1101:12)
    at process._tickCallback (internal/process/next_tick.js:152:19) code: 'ECONNRESET' }



md5-988987fef0feed585119ccc2fe5450ba



~/node-training> npm config ls -l
; cli configs
long = true
metrics-registry = "https://registry.npmjs.org/"
scope = ""
user-agent = "npm/6.1.0 node/v9.5.0 darwin x64"

; userconfig /Users/katsanos/.npmrc
strict-ssl = false

; default values
access = null
allow-same-version = false
also = null
always-auth = false
audit = true
auth-type = "legacy"
bin-links = true
browser = null
ca = null
cache = "/Users/katsanos/.npm"
cache-lock-retries = 10
cache-lock-stale = 60000
cache-lock-wait = 10000
cache-max = null
cache-min = 10
cafile = undefined
cert = null
cidr = null
color = true
commit-hooks = true
depth = null
description = true
dev = false
dry-run = false
editor = "vi"
engine-strict = false
fetch-retries = 2
fetch-retry-factor = 10
fetch-retry-maxtimeout = 60000
fetch-retry-mintimeout = 10000
force = false
git = "git"
git-tag-version = true
global = false
global-style = false
globalconfig = "/usr/local/etc/npmrc"
globalignorefile = "/usr/local/etc/npmignore"
group = 1493692218
ham-it-up = false
heading = "npm"
https-proxy = null
if-present = false
ignore-prepublish = false
ignore-scripts = false
init-author-email = ""
init-author-name = ""
init-author-url = ""
init-license = "ISC"
init-module = "/Users/katsanos/.npm-init.js"
init-version = "1.0.0"
json = false
key = null
legacy-bundling = false
link = false
local-address = undefined
loglevel = "notice"
logs-max = 10
; long = false (overridden)
maxsockets = 50
message = "%s"
; metrics-registry = null (overridden)
no-proxy = null
node-options = null
node-version = "9.5.0"
offline = false
onload-script = null
only = null
optional = true
otp = null
package-lock = true
package-lock-only = false
parseable = false
prefer-offline = false
prefer-online = false
prefix = "/usr/local"
production = false
progress = true
proxy = null
read-only = false
rebuild-bundle = true
registry = "https://registry.npmjs.org/"
rollback = true
save = true
save-bundle = false
save-dev = false
save-exact = false
save-optional = false
save-prefix = "^"
save-prod = false
scope = ""
script-shell = null
scripts-prepend-node-path = "warn-only"
searchexclude = null
searchlimit = 20
searchopts = ""
searchstaleness = 900
send-metrics = false
shell = "/usr/local/bin/fish"
shrinkwrap = true
sign-git-tag = false
sso-poll-frequency = 500
sso-type = "oauth"
; strict-ssl = true (overridden)
tag = "latest"
tag-version-prefix = "v"
timing = false
tmp = "/var/folders/kn/3cnpbcsx60n4fx_jv6sf4l80_mdkps/T"
umask = 18
unicode = true
unsafe-perm = true
usage = false
user = 356960985
; user-agent = "npm/{npm-version} node/{node-version} {platform} {arch}" (overridden)
userconfig = "/Users/katsanos/.npmrc"
version = false
versions = false
viewer = "man"

EDIT : il me manquait req.end() . Travaux

J'ai le même bug. Le POST fonctionne lorsque Content-Length est ajouté à la demande. J'espère que cela vous aide les gars:
'Content-Length' : Buffer.byteLength(data) //Content-Length est nécessaire pour un POST

Dans mon cas, j'ai pu contourner le problème en définissant l'en-tête Connection: keep-alive .

SAUVEZ MA JOURNÉE !

Je creuse un peu.
J'ai un problème arrière une fois par semaine avec une demande lors de l'envoi du POST au serveur nodejs.
Après avoir utilisé le balancier, j'ai découvert que nodejs suspendait simplement la connexion si la demande était mal formée.

On dirait qu'un bogue arrière se produit lorsque la requête POST est transmise à http.request

Dans mon cas, le corps a été envoyé sans les derniers symboles et PEUT-ÊTRE était-ce dû à un mauvais calcul de Content-Length dans setContentLength()

L'utilisation du protocole 'http' au lieu du protocole 'https' résout également le problème.

C'est très frustrant. Je n'ai pas de contrôle sur le serveur mais je ne peux pas faire de POST à ​​partir de Nodejs (à l'aide d'une requête ou d'un superagent), mais je peux faire curl ou Postman avec succès. Encore plus fou, l'appel réussirait si je mettais en pause l'utilisation du débogueur sur l'instruction de requête et continuais.

Dans mon cas, je viens de supprimer l'en-tête 'Host', résolu.

Nous avons rencontré ce problème après la mise à niveau vers un nouveau nodejs ( 10.16.3 ). Côté client, nous avons utilisé l'agent http nodejs avec keepAlive: true . Il semble que ce qui suit s'est produit :

• le client utilise un socket gratuit pour faire une requête
• dans le même temps, le serveur ferme le socket à cause du paramètre keepAliveTimeout qui est apparu dans nodejs version 8

Solution
Jusqu'à présent, nous avons trouvé deux solutions :
1) Côté serveur, désactivez keepAliveTimeout en le définissant égal à 0
2) Fermez les sockets libres en moins de keepAliveTimeout value (par défaut 5 secondes). L'agent http par défaut ne prend pas en charge une telle capacité (le paramètre timeout ne le fait pas). Nous avons donc utilisé agentkeepalive lib

const HttpsAgent = require('agentkeepalive').HttpsAgent;

const agent = new HttpsAgent({
    freeSocketTimeout: 4000
});

let req = http.get(options, (res) => {
    ...........
    ...........
}).on('error', function(e) {
        console.error(e);
});

Essaye ça.

Nous sommes confrontés à un problème similaire - actuellement, nous utilisons 6.11.x mais nous avons essayé le nœud 10 mais cela n'aide pas.

Nous avons même essayé de mettre à niveau le module de demande + d'ajouter toutes les suggestions fournies mais aucune aide.

Toute autre idée ou aide au dépannage.

nous sommes en mesure de résoudre ce problème - notre passerelle API avait un paramètre de délai d'attente qui causait ce problème. merci de l'avoir examiné.

nous sommes en mesure de résoudre ce problème - notre passerelle API avait un paramètre de délai d'attente qui causait ce problème. merci de l'avoir examiné.

Bonjour, pouvez-vous me dire quel type de paramètre de délai d'attente a conduit à ce problème

J'ai le même problème lorsque je teste mes routes avec chai-http. l'absurde c'est que les trois premiers passent ok !! j'essaye d'y faire face toute la journée

voici mon code :
```
log("test de fonctionnement")
it("tester les routes /login", done => {
chaï
.request(serveur)
.post("/connexion")
.envoyer({ })
.end(function(err, res) {
s'attendre (err).à.être.nulle ;
attendre(res.statut).to.not.equal(404);
expect(res.body.message).to.not.be.equal("Not Found");
Fini();
});
});

log (échec du test avec erreur : raccrochage du socket)
it('tester la route /getResetCodePassword', (done)=> {
chaï
.request(serveur)
.patch("/getResetCodePassword")
.envoyer({ })
.end( (err,res) => {
console.log(err);
Fini();
})
})

```