New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Http connections aborted after 5s / keepAliveTimeout #13391

Closed
pbininda opened this Issue Jun 2, 2017 · 32 comments

Comments

Projects
None yet
10 participants
@pbininda
Contributor

pbininda commented Jun 2, 2017

  • Version: v8.0.0
  • Platform: Windows 10, 64bit
  • Subsystem: http

Short Description

Node 8 introduced a change in the handling of http keep-alive connections. IMHO, this is (at least) a breaking change. When an http server does long-running requests (>5s), and the client requests a Connection: keep-alive connection, the http server closes the connection after 5s. This potentially causes browsers to re-send the request even if it is a POST request.

To Reproduce

clone https://github.com/pbininda/node8keepAliveTimeout and npm install. Then

    npm test

Starts a little express server (server.js) and a client.

  • The server is a standard express server with a long running post request (/longpost takes 10s).
  • The client calls the POST /longpost with a preflight OPTIONS /longpost.

The test runs through fine on node 6 and node 7:

> node test.js

got request OPTIONS /longpost
got options response 200
sending post request
got request POST /longpost
got post response 200 { status: 'OK' }

but fails on node 8 with

> node test.js

got request OPTIONS /longpost
got options response 200
sending post request
got request POST /longpost
C:\Users\pbininda\projects\ATRON\node8keepAliveTimeout\client.js:39
            throw err;
            ^

Error: socket hang up
    at createHangUpError (_http_client.js:343:15)
    at Socket.socketOnEnd (_http_client.js:435:23)
    at emitNone (events.js:110:20)
    at Socket.emit (events.js:207:7)
    at endReadableNT (_stream_readable.js:1045:12)
    at _combinedTickCallback (internal/process/next_tick.js:102:11)
    at process._tickCallback (internal/process/next_tick.js:161:9)

Browser Retries

It seems, most of the major browsers (Chrome, Firefox, Edge) implement https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.4. Since the server closes the connection on which it received the POST request before sending an answer, the Browsers re-send the POST. Note that you don't see the re-send in chrome dev tools but using Wireshark shows the retransmission. To have a look at this, run

    npm start

which launches the server (server.js) and then load browsertest.html in chrome. This runs browsertest.js in the browser which does a simple $.ajax request against the server. On the server side you will see:

> node server.js

got request OPTIONS /longpost
got request POST /longpost
got request POST /longpost
format called 5003ms after previous

This shows, that the server received two POST requests the second one 5s after the first one, even though the browser client code only does one request.

Bug or Breaking Change?

I'm not sure if this is a bug or a breaking change. It probably got introduced through #2534. It only seems to happen when two connections are used (that's why the prefight OPTIONS is forced to happen in my code), so it may be that the wrong connection is being closed here.

Workaround

Setting the keepAliveTimeout (see https://nodejs.org/dist/latest-v8.x/docs/api/http.html#http_server_keepalivetimeout) of the http server to a value greater than the maximum duration of a request solves the problem. You can try this with

    npm start -- --keepAliveTimeout 20000

and then in another terminal

    node client.js
@ChALkeR

This comment has been minimized.

Show comment
Hide comment
@ChALkeR

ChALkeR Jun 2, 2017

Member

/cc @indutny @tshemsedinov @aqrln
Could be related to #2534.

Member

ChALkeR commented Jun 2, 2017

/cc @indutny @tshemsedinov @aqrln
Could be related to #2534.

@ChALkeR ChALkeR added the http label Jun 2, 2017

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Jun 2, 2017

Member

Thanks for the ping, I'll be able look into this in a few hours.

Member

aqrln commented Jun 2, 2017

Thanks for the ping, I'll be able look into this in a few hours.

@aqrln aqrln self-assigned this Jun 2, 2017

@lvpro

This comment has been minimized.

Show comment
Hide comment
@lvpro

lvpro Jun 2, 2017

Thanks for bringing this up @pbininda. We hit this issue as well when running requests longer than a few seconds. We also see multiple POSTs effecting all browsers on 8 ... reverted back to 7.10 and all is well. Seems like a pretty pernicious bug. We're using Koa 1.x middleware on Linux.

lvpro commented Jun 2, 2017

Thanks for bringing this up @pbininda. We hit this issue as well when running requests longer than a few seconds. We also see multiple POSTs effecting all browsers on 8 ... reverted back to 7.10 and all is well. Seems like a pretty pernicious bug. We're using Koa 1.x middleware on Linux.

@juanecabellob

This comment has been minimized.

Show comment
Hide comment
@juanecabellob

juanecabellob Jun 2, 2017

Same behaviour here; request bit longer than usual and the browser kept resending the request. A general remark is that Firefox and Chrome did resend the request, but Safari didn't. Using Express server 4.15.2. Finally, we reverted to 7.10 and is working normally.

juanecabellob commented Jun 2, 2017

Same behaviour here; request bit longer than usual and the browser kept resending the request. A general remark is that Firefox and Chrome did resend the request, but Safari didn't. Using Express server 4.15.2. Finally, we reverted to 7.10 and is working normally.

@pbininda

This comment has been minimized.

Show comment
Hide comment
@pbininda

pbininda Jun 3, 2017

Contributor

Thanks for the note regarding Safari, I'll change the wording regarding "all major browsers" 😓

Contributor

pbininda commented Jun 3, 2017

Thanks for the note regarding Safari, I'll change the wording regarding "all major browsers" 😓

@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Jun 5, 2017

Member

Ugh... sorry for the delay, I was more busy that I hoped for. Let's fix it today. Thanks a lot for a detailed report and reproduction!

Member

aqrln commented Jun 5, 2017

Ugh... sorry for the delay, I was more busy that I hoped for. Let's fix it today. Thanks a lot for a detailed report and reproduction!

@lvpro

This comment has been minimized.

Show comment
Hide comment
@lvpro

lvpro Jun 8, 2017

Confirmed issue still present in release 8.1 as well.

lvpro commented Jun 8, 2017

Confirmed issue still present in release 8.1 as well.

@aqrln aqrln referenced this issue Jun 8, 2017

Closed

http: fix timeout reset after keep-alive timeout #13549

3 of 3 tasks complete
@aqrln

This comment has been minimized.

Show comment
Hide comment
@aqrln

aqrln Jun 8, 2017

Member

@pbininda @lvpro @juanecabellob I'm very sorry for not making it in time for the 8.1 release. I took a look at the reproduction back then, but didn't have an opportunity to debug it until now. #13549 should fix it.

Member

aqrln commented Jun 8, 2017

@pbininda @lvpro @juanecabellob I'm very sorry for not making it in time for the 8.1 release. I took a look at the reproduction back then, but didn't have an opportunity to debug it until now. #13549 should fix it.

@lvpro

This comment has been minimized.

Show comment
Hide comment
@lvpro

lvpro Jun 8, 2017

Don't be sorry @aqrln! Thank you very much for getting this resolved! :)

lvpro commented Jun 8, 2017

Don't be sorry @aqrln! Thank you very much for getting this resolved! :)

@pbininda

This comment has been minimized.

Show comment
Hide comment
@pbininda

pbininda Jun 8, 2017

Contributor

@aqrln No problem, I can keep the server.keepAliveTimeout workaround in place until the fix is released. Thanks for your effort.

Contributor

pbininda commented Jun 8, 2017

@aqrln No problem, I can keep the server.keepAliveTimeout workaround in place until the fix is released. Thanks for your effort.

aqrln added a commit to aqrln/node that referenced this issue Jun 12, 2017

http: fix timeout reset after keep-alive timeout
Fix the logic of resetting the socket timeout of keep-alive HTTP
connections and add two tests:

* `test-http-server-keep-alive-timeout-slow-server` is a regression test
  for GH-13391.  It ensures that the server-side keep-alive timeout will
  not fire during processing of a request.

* `test-http-server-keep-alive-timeout-slow-headers` ensures that the
  regular socket timeout is restored as soon as a client starts sending
  a new request, not as soon as the whole message is received, so that
  the keep-alive timeout will not fire while, e.g., the client is
  sending large cookies.

Refs: nodejs#2534
Fixes: nodejs#13391

@aqrln aqrln closed this in d71718d Jun 13, 2017

MylesBorins added a commit that referenced this issue Jun 13, 2017

http: fix timeout reset after keep-alive timeout
Fix the logic of resetting the socket timeout of keep-alive HTTP
connections and add two tests:

* `test-http-server-keep-alive-timeout-slow-server` is a regression test
  for GH-13391.  It ensures that the server-side keep-alive timeout will
  not fire during processing of a request.

* `test-http-server-keep-alive-timeout-slow-client-headers` ensures that
  the regular socket timeout is restored as soon as a client starts
  sending a new request, not as soon as the whole message is received,
  so that the keep-alive timeout will not fire while, e.g., the client
  is sending large cookies.

Refs: #2534
Fixes: #13391
PR-URL: #13549
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>

MylesBorins added a commit that referenced this issue Jun 13, 2017

http: fix timeout reset after keep-alive timeout
Fix the logic of resetting the socket timeout of keep-alive HTTP
connections and add two tests:

* `test-http-server-keep-alive-timeout-slow-server` is a regression test
  for GH-13391.  It ensures that the server-side keep-alive timeout will
  not fire during processing of a request.

* `test-http-server-keep-alive-timeout-slow-client-headers` ensures that
  the regular socket timeout is restored as soon as a client starts
  sending a new request, not as soon as the whole message is received,
  so that the keep-alive timeout will not fire while, e.g., the client
  is sending large cookies.

Refs: #2534
Fixes: #13391
PR-URL: #13549
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Brian White <mscdex@mscdex.net>
@awb99

This comment has been minimized.

Show comment
Hide comment
@awb99

awb99 Oct 15, 2017

I have this issue too with webpack-dev-server. It somehow does not work.

How would I pass the paratmeter keepAlive Timeout so that the default timeout is 20 secs?

Above this is the example

npm start -- --keepAliveTimeout 20000

I tried this:

 npm run-script start -- --"keepAliveTimeout 20000"

It gets expanded to:

webpack-dev-server --inline --hot --history-api-fallback  --public --host 104.222.96.51 --port 9090 "--keepAliveTimeout 20000"

Unfortunately it does not have any effect.

awb99 commented Oct 15, 2017

I have this issue too with webpack-dev-server. It somehow does not work.

How would I pass the paratmeter keepAlive Timeout so that the default timeout is 20 secs?

Above this is the example

npm start -- --keepAliveTimeout 20000

I tried this:

 npm run-script start -- --"keepAliveTimeout 20000"

It gets expanded to:

webpack-dev-server --inline --hot --history-api-fallback  --public --host 104.222.96.51 --port 9090 "--keepAliveTimeout 20000"

Unfortunately it does not have any effect.

@rickywu

This comment has been minimized.

Show comment
Hide comment
@rickywu

rickywu Oct 18, 2017

This problem still exists in node 8.7.0

rickywu commented Oct 18, 2017

This problem still exists in node 8.7.0

@Delagen

This comment has been minimized.

Show comment
Hide comment
@Delagen

Delagen Oct 18, 2017

@rickywu what problem and show your code that produces problem

Delagen commented Oct 18, 2017

@rickywu what problem and show your code that produces problem

@awb99

This comment has been minimized.

Show comment
Hide comment
@awb99

awb99 Oct 18, 2017

@rickywu I am using webpack dev server to host a bundle.js file that is about 5 MB in size.

webpack-dev-server --inline --hot --history-api-fallback  --public --host 127.0.0.1 --port 9090 --keepAliveTimeout 20000

It all worked when the bundle size was 2 MB. Now that it is bigger, I do get timeouts in the browser.
I believe that it is a pretty well known problem. The first link shows some solutions, which unfortunately do not work; the other two links show that the issue is there on webpack-dev-server and also with angular-cli

#13391
webpack/webpack-dev-server#1044
angular/angular-cli#7563

awb99 commented Oct 18, 2017

@rickywu I am using webpack dev server to host a bundle.js file that is about 5 MB in size.

webpack-dev-server --inline --hot --history-api-fallback  --public --host 127.0.0.1 --port 9090 --keepAliveTimeout 20000

It all worked when the bundle size was 2 MB. Now that it is bigger, I do get timeouts in the browser.
I believe that it is a pretty well known problem. The first link shows some solutions, which unfortunately do not work; the other two links show that the issue is there on webpack-dev-server and also with angular-cli

#13391
webpack/webpack-dev-server#1044
angular/angular-cli#7563

@Delagen

This comment has been minimized.

Show comment
Hide comment
@Delagen

Delagen Oct 19, 2017

I have this bug till nide 8.2 as i know. Now it fixed and does not related with this. I have bundles about 10Mb. And if server respond then all fine. I recommed to tune mtu if you using some vpn

Delagen commented Oct 19, 2017

I have this bug till nide 8.2 as i know. Now it fixed and does not related with this. I have bundles about 10Mb. And if server respond then all fine. I recommed to tune mtu if you using some vpn

@awb99

This comment has been minimized.

Show comment
Hide comment
@awb99

awb99 Oct 19, 2017

@Delagen This is really strange. I run this on a dedicated server with direct IP. I have solved this issue so far, by basically creating a bundle that I now serve via express.js where I set the timeout in code. To me all the descriptions fit 100% to the issue that came up with node recently. I cannot run the webpack dev server anymore on my server; it only works on the localhost on my development machine, as there I do not have any transfer delay.

awb99 commented Oct 19, 2017

@Delagen This is really strange. I run this on a dedicated server with direct IP. I have solved this issue so far, by basically creating a bundle that I now serve via express.js where I set the timeout in code. To me all the descriptions fit 100% to the issue that came up with node recently. I cannot run the webpack dev server anymore on my server; it only works on the localhost on my development machine, as there I do not have any transfer delay.

@rickywu

This comment has been minimized.

Show comment
Hide comment
@rickywu

rickywu Oct 20, 2017

@Delagen see this issue

I used server.keepAliveTimeout=30000 in app.js solved, but I think the default value 5s is too short.

rickywu commented Oct 20, 2017

@Delagen see this issue

I used server.keepAliveTimeout=30000 in app.js solved, but I think the default value 5s is too short.

@Delagen

This comment has been minimized.

Show comment
Hide comment
@Delagen

Delagen Oct 20, 2017

@rickywu As for me error on express was in repeating request callback. I have no any problems with expressjs in Nodejs 8.7.0. I only set timeout as I have heavy requests, that need up to minute to begin response. But I don't set ant keepAliveTimeout

Delagen commented Oct 20, 2017

@rickywu As for me error on express was in repeating request callback. I have no any problems with expressjs in Nodejs 8.7.0. I only set timeout as I have heavy requests, that need up to minute to begin response. But I don't set ant keepAliveTimeout

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 20, 2017

Member

FWIW, there is a PR open that's dealing with this: #15791 and there's a more recent (open) issue: #15082

Member

apapirovski commented Oct 20, 2017

FWIW, there is a PR open that's dealing with this: #15791 and there's a more recent (open) issue: #15082

@Delagen

This comment has been minimized.

Show comment
Hide comment
@Delagen

Delagen Oct 20, 2017

@apapirovski As I understand It only occurs when use of TLS in node?

Delagen commented Oct 20, 2017

@apapirovski As I understand It only occurs when use of TLS in node?

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 20, 2017

Member

@Delagen No, it occurs in both tls & net (the PR just fixes both tls & net issues related to it). See #15082 for a good explanation of what triggers it.

But to summarize, once Node starts writing data, the timeout starts ticking (whether it's keep alive or the regular one) and it completely ignores whether any writing is still going on or not. The timer is only updated when a write starts or ends. That's why most reports of this issue have to do with downloading/serving large files. Also this issue has existed for a very long time, it just wasn't super obvious before keepAliveTimeout because the regular timeout is 120s.

Member

apapirovski commented Oct 20, 2017

@Delagen No, it occurs in both tls & net (the PR just fixes both tls & net issues related to it). See #15082 for a good explanation of what triggers it.

But to summarize, once Node starts writing data, the timeout starts ticking (whether it's keep alive or the regular one) and it completely ignores whether any writing is still going on or not. The timer is only updated when a write starts or ends. That's why most reports of this issue have to do with downloading/serving large files. Also this issue has existed for a very long time, it just wasn't super obvious before keepAliveTimeout because the regular timeout is 120s.

@rickywu

This comment has been minimized.

Show comment
Hide comment
@rickywu

rickywu Oct 21, 2017

@Delagen What's the size of your data per request? My data is about 3Mb
I use debug tool monitor network, transmission suspend after 6s if not set keep alive timeout.

rickywu commented Oct 21, 2017

@Delagen What's the size of your data per request? My data is about 3Mb
I use debug tool monitor network, transmission suspend after 6s if not set keep alive timeout.

@Delagen

This comment has been minimized.

Show comment
Hide comment
@Delagen

Delagen Oct 21, 2017

About 5 mb max, but seems I have fast channel, so I don't take this timeout

Delagen commented Oct 21, 2017

About 5 mb max, but seems I have fast channel, so I don't take this timeout

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 21, 2017

Member

FYI A fix for this just landed on master so it should be in 8.x LTS & 9.x at some point within the next month. With the fix there should no longer be a need to bump up the keepAliveTimeout just so transfers don't timeout.

Member

apapirovski commented Oct 21, 2017

FYI A fix for this just landed on master so it should be in 8.x LTS & 9.x at some point within the next month. With the fix there should no longer be a need to bump up the keepAliveTimeout just so transfers don't timeout.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Oct 23, 2017

Member

@apapirovski can you link to the fix please :D

v4.x and v6.x are unaffected correct?

Member

MylesBorins commented Oct 23, 2017

@apapirovski can you link to the fix please :D

v4.x and v6.x are unaffected correct?

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 23, 2017

Member

@MylesBorins It's here a627c5f

Let me confirm re: v6.x

Member

apapirovski commented Oct 23, 2017

@MylesBorins It's here a627c5f

Let me confirm re: v6.x

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 23, 2017

Member

v6.x is affected. Probably v4.x too.

Here's a way to test:

const http = require('http');

const server = http.createServer((req, res) => {

  var content = Buffer.alloc(30000000, 0x44);

  res.writeHead(200, {
    'Content-Type': 'application/octet-stream',
    'Content-Length': content.length.toString(),
    'Vary': 'Accept-Encoding'
  });

  var handle = res.socket._handle;
  var endRc = res.end(content, function() {
    console.log(handle.writeQueueSize);
  });

  res.end();
});
server.timeout = 5000;

server.listen(8000);
curl -v http://localhost:8000/ | dd bs=1 of=/dev/null

I don't know if my code can be backported straight up though. Maybe label with backport requested and I'll try to get around to figuring out how to make it work on those.

Member

apapirovski commented Oct 23, 2017

v6.x is affected. Probably v4.x too.

Here's a way to test:

const http = require('http');

const server = http.createServer((req, res) => {

  var content = Buffer.alloc(30000000, 0x44);

  res.writeHead(200, {
    'Content-Type': 'application/octet-stream',
    'Content-Length': content.length.toString(),
    'Vary': 'Accept-Encoding'
  });

  var handle = res.socket._handle;
  var endRc = res.end(content, function() {
    console.log(handle.writeQueueSize);
  });

  res.end();
});
server.timeout = 5000;

server.listen(8000);
curl -v http://localhost:8000/ | dd bs=1 of=/dev/null

I don't know if my code can be backported straight up though. Maybe label with backport requested and I'll try to get around to figuring out how to make it work on those.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Oct 23, 2017

Member

@apapirovski please make a backport to the v6.x and v4.x branches.

We are doing a maintenance release of v4.x soon which can be postponed for this

Member

MylesBorins commented Oct 23, 2017

@apapirovski please make a backport to the v6.x and v4.x branches.

We are doing a maintenance release of v4.x soon which can be postponed for this

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 23, 2017

Member

Ok, I labeled the PR and will work on it this week. Will keep you posted on it. Let me know if it lands cleanly on v8.x or not — want to make sure it makes it into the first LTS release of that.

Member

apapirovski commented Oct 23, 2017

Ok, I labeled the PR and will work on it this week. Will keep you posted on it. Let me know if it lands cleanly on v8.x or not — want to make sure it makes it into the first LTS release of that.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins

MylesBorins Oct 23, 2017

Member

@apapirovski I just landed it in v8.x-staging in f6a725e, it should hopefully go out in tomorrows release

Member

MylesBorins commented Oct 23, 2017

@apapirovski I just landed it in v8.x-staging in f6a725e, it should hopefully go out in tomorrows release

@apapirovski

This comment has been minimized.

Show comment
Hide comment
@apapirovski

apapirovski Oct 23, 2017

Member

@MylesBorins You'll need the other commit: aaf2a1c — they probably should've landed as one or I should've indicated that the 2nd one depends on the first working properly. My bad.

Member

apapirovski commented Oct 23, 2017

@MylesBorins You'll need the other commit: aaf2a1c — they probably should've landed as one or I should've indicated that the 2nd one depends on the first working properly. My bad.

@MylesBorins

This comment has been minimized.

Show comment
Hide comment
@MylesBorins
Member

MylesBorins commented Oct 23, 2017

@apapirovski done

landed in eeef06a

jasnell added a commit that referenced this issue Dec 28, 2017

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: #17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>

MylesBorins added a commit that referenced this issue Jan 8, 2018

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: #17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>

MylesBorins added a commit that referenced this issue Jan 9, 2018

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: #17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>

MylesBorins added a commit that referenced this issue Jan 9, 2018

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: #17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>

ribizli referenced this issue in apollographql/apollo-server Jan 10, 2018

gibfahn added a commit that referenced this issue Jan 24, 2018

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: #17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>

msoechting added a commit to hpicgs/node that referenced this issue Feb 5, 2018

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: nodejs#17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>

msoechting added a commit to hpicgs/node that referenced this issue Feb 7, 2018

doc: doc imitating the old behavior of http.Server.keepAliveTimeout
Documenting the best way to imitate the old behavior saves time for people
migrating from older versions. (E.g. for unexpected ECONNRESET)

It isn't immediately obvious if earlier nodejs versions behaved the same
way as nodejs 8 does with keepAliveTimeout = 0.
From 0aa7ef5, it seems like they behave
the same way.

Related to issues such as #13391 that show up when migrating to node 8

PR-URL: nodejs#17660
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Anatoli Papirovski <apapirovski@mac.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment