Repository navigation
http - calls from an external IP close after 5-20 seconds using response.end and Content-Length header is set (Node 8.X) #14869
Description
- Version: v8.0.0, v8.1.0, v8.4.0
- Platform: Linux 4.10.0-28-generic 32~16.04.2-Ubuntu SMP Thu Jul 20 10:19:48 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux, Linux 2.6.32-573.3.1.el6.x86_64 1 SMP Thu Aug 13 22:55:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
- Subsystem: http
Executing a request from an external IP address, results in a closed connection after about 5 - 20 seconds when the Content-Length header is set. When Content-Length is not set, it seems ok.
Executing a request locally always seems to respect the server timeout regardless of Content-Length.
This works correctly in Node 7.10.1.
Using the following code (thanks to Doug Wilson at ExpressJS):
var fs = require('fs');
var http = require('http');
var wordsFile = '/usr/share/dict/words';
function app (req, res) {
switch (req.url) {
case '/send':
var contents = fs.readFileSync(wordsFile);
res.setHeader('Content-Length', contents.length);
res.end(contents);
break;
case '/sendNoLength':
var contents = fs.readFileSync(wordsFile);
res.end(contents);
break;
default:
res.statusCode = 404;
res.end();
}
}
var server = http.createServer(app);
server.timeout = 120000 * 5;
server.listen('3000');I've changed my IPs here to Google's...
> wget 8.8.8.8:3000/send --limit-rate=5k
--2017-08-16 18:03:56-- http://8.8.8.8:3000/send
Connecting to 8.8.8.8:3000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 938848 (917K)
Saving to: “send” --- 64,990 5.00K/s in 13s
2017-08-16 18:04:09 (5.00 KB/s) - Connection closed at byte 64990. Retrying.
--2017-08-16 18:04:10-- (try: 2) http://8.8.8.8:3000/send
Connecting to 8.8.8.8:3000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 938848 (917K)
Saving to: “send” --- 67,724 5.00K/s in 13s
2017-08-16 18:04:23 (5.00 KB/s) - Connection closed at byte 67724. Retrying.
--2017-08-16 18:04:25-- (try: 3) http://8.8.8.8:3000/send
Connecting to 8.8.8.8:3000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 938848 (917K)
Saving to: “send” --- 62,256 5.00K/s in 12s
2017-08-16 18:04:37 (5.00 KB/s) - Connection closed at byte 67724. Retrying.
--2017-08-16 18:04:40-- (try: 4) http://8.8.8.8:3000/send
Connecting to 8.8.8.8:3000... connected.
HTTP request sent, awaiting response... 200 OK
Length: 938848 (917K)
Saving to: “send” --- 64,990 5.00K/s in 13s
2017-08-16 18:04:53 (5.00 KB/s) - Connection closed at byte 67724. Retrying.It works when you don't set the Content-Length header:
> wget 8.8.8.8:3000/sendNoLength --limit-rate=5k
--2017-08-16 18:22:49-- http://8.8.8.8:3000/sendNoLength
Connecting to 8.8.8.8:3000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified
Saving to: “sendNoLength”
2017-08-16 18:25:52 (5.00 KB/s) - “sendNoLength” saved [938848]Paper trail of how I got here
angular/angular-cli#7197
webpack/webpack-dev-server#1044
expressjs/express#3392
Activity
[-]http - calls from an external IP close after 5-20 seconds when using response.end (Node 8.X)[/-][+]http - calls from an external IP close after 5-20 seconds using response.end and Content-Length is set (Node 8.X)[/+][-]http - calls from an external IP close after 5-20 seconds using response.end and Content-Length is set (Node 8.X)[/-][+]http - calls from an external IP close after 5-20 seconds using response.end and Content-Length header is set (Node 8.X)[/+]bnoordhuis commentedon Aug 18, 2017
I'm afraid I can't reproduce and honestly, I can't think of anything in node that would cause that. I think a more likely explanation is that there is something on your local system or network that causes the issue.
mtraynham commentedon Aug 18, 2017
@bnoordhuis If it helps, instead of using Linux Mint 18 as the node server, I've tried hosting on a Mac OSX Sierra (10.12.6) from a completely different network and it's happening here as well. The differences here being, size of words file and it seemingly takes much longer than 15 seconds, instead taking about 50-70 seconds. I'm not sure if the connection closing at the same byte every time is somewhat suspect.
Node 8.4.0
Mac OSX 10.12.6
(obfuscated my IPs)
bnoordhuis commentedon Aug 18, 2017
I tried it on a different box with, going by the file size, probably the same words file as you (Ubuntu 16.04) and it still works. It takes about three minutes to download the file but it doesn't error, Content-Length header or not, local or external interface.
mtraynham commentedon Aug 18, 2017
I also tried the MacOSX with Node 7.10.1 and it seems to work correctly. It does eventually timeout according to the server timeout, but it seems to be at almost 11 minutes rather than 10 which is weird...
mtraynham commentedon Aug 18, 2017
Also to add, I tried hosting on a bare bones AWS EC2 - Centos 6 (Linux 2.6.32-573.3.1.el6.x86_64 SMP Thu Aug 13 22:55:16 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux) machine. I had to ship a different file, but it still experiences the same symptoms as before.
Previously, I had been using NVM to handle installations of Node, but this time I tried just the Linux x64 binaries. With v8.4.0, sure enough, it fails the request after about 15 seconds when Content-Length is set.
Tried the v7.10.1 binary and it seems to timeout at about 10 minutes per server timeout.
Tried with v8.0.0 binary, and it seems to fail at 15 seconds like before.
sk91 commentedon Aug 23, 2017
same issue node v8.4.0
sk91 commentedon Aug 23, 2017
@mtraynham it seems to be related to this commit: a7f5c9c
will fix your test
mtraynham commentedon Aug 29, 2017
@sk91 You are a life saver! I do believe that is it!
It looks like this has already been discovered and fixed with #13391, so I will close this and convey the message back upstream to the other issues that lead me here.