Repository navigation
http, net: socket "inactivity" timeout #3319
Description
d258fb0 added this explanation to server.timeout:
The number of milliseconds of inactivity before a socket is presumed to have timed out.
I noticed that long running (but active) requests like file uploads were cancelled after the timeout had passed and I'm almost certain that there is no actual code that checks for activity on a socket.
Should we update the docs so they state that the socket timeout is actually unconditional? Alternatively, we could possibly reset the timeout on activity, but that will have a perf impact.
Activity
brendanashworth commentedon Oct 12, 2015
Please correct me if I'm wrong, but doesn't net use
_unrefTimerto handle timeouts? And http just inherits that?julien-f commentedon Nov 13, 2015
I have the same issue, a long running post request is killed by the timeout even though there is some activity.
tflanagan commentedon Nov 13, 2015
This sounds like a code bug rather than a doc bug.
Edit: Is this the default 120 seconds found at /lib/_http_server.js:243? I think I've unknowingly run into this issue before. I wrote a small helper script that bugged out on a couple files the first time, but, with no change, worked again the second time. Couple months ago, haven't used it since tho
silverwind commentedon Nov 14, 2015
@tflanagan yes, 120 seconds defined here. You can also do it on a per-request basis with
res.setTimeout, which is useful if you only want POSTs to have a longer timeout, for example.I'm not sure if an implementation that keeps sockets alive on activity isn't a DoS risk, so I marked this a docs issue.
tflanagan commentedon Nov 14, 2015
It certainly is a DoS risk. However, an unconditional timeout is one extreme, whereas the subsequent documentation on setting it to
0is the other extreme.Perhaps a new
activityTimeoutsetting is in order? In parallel totimeout.vvo commentedon Dec 9, 2015
Hi, I was also surprised by this. I was used to a socket inactivity timeout since long time with nodejs request.setTimeout but it is no more, it's now a global timeout.
Should we fix the code or the docs so?
silverwind commentedon Mar 30, 2016
Closing in favor of #5899 which has a bit more detail and a example.