-
Notifications
You must be signed in to change notification settings - Fork 7.3k
http response not emitting data #2457
Comments
Can you post the wireshark traces? With what version of Node are you testing it? |
I'm using node v0.6.6. Here are 2 traces taken with curl: Let me know if you need the traces taken with node (they are similar, but the notok trace will not have the body). |
Correct me if I'm wrong but it looks like the TRENDNet camera doesn't send a full response. It should be 5858 bytes big according to the Content-Length header but it seems only 3916 bytes were actually sent. |
This is only partial because I hit "ctrl+c". The Content-Length header is not part of the HTTP headers, it's part of the MJPEG stream (we get a Content-Length header for each image, directly in the body, separated by the boundary ("myboundary")). |
Here is another trace, with more packets: You'll see that the --myboundary with Content-Type/Content-Length is repeated in the body. These are headers for the MJPEG standard. |
@legege: Thanks for the report. This is similar to #1711. reproduce: var net = require('net');
var http = require('http');
var server = net.createServer({ allowHalfOpen: true }, function(socket) {
console.log('SERVER: writing status line');
socket.write('HTTP/1.1 200 ok\r\n');
setTimeout(function() {
console.log('SERVER: writhing headers');
//socket.write('Connection: close\r\n');
socket.write('Content-Type: text/plain\r\n\r\n');
setTimeout(function() {
console.log('SERVER: writing body');
socket.write('Hello');
setTimeout(function() {
console.log('SERVER: closing');
socket.end();
}, 10);
}, 10);
}, 10);
}).listen(3000, function() {
var req = http.get({ port: 3000 }, function(res) {
res.on('data', function(buf) {
console.log('CLIENT: data', buf.toString());
});
res.on('end', function() {
console.log('CLIENT: end');
server.close();
});
});
}); result:
So, this problem is related with Keep-Alive. In this case (neither @legege: You should not use |
@koichik Thanks a lot for this quick investigation and patch! |
With HTTP/1.1, if neither Content-Length nor Transfer-Encoding is present, section 4.4 of RFC 2616 suggests http-parser needs to read a response body until the connection is closed (except the response must not include a body) See also nodejs/node-v0.x-archive#2457. Fixes #72
I'm trying to proxy a MJPEG HTTP stream and I found an issue with the http module or the http parser. A MJPEG HTTP response doesn't have a Content-Length header, and should normally, read the response body until EOF. However, I found that in particular cases, the http module doesn't read until EOF, and simply close the connection after having received the headers.
Here is the code I'm using to proxy the request:
The problem occurs when proxying a MJPEG stream from a TRENDNet TV-IP422 camera. It works fine with an Axis camera.
I have wireshark traces of the issue. The only difference I see from a working response versus this one, is with the way TCP segments are sent back (on TV-IP422, the first segment is for the HTTP response status code, the next is for HTTP response headers, the next is for the MJPEG stream, etc; on Axis, the first segment is for HTTP response status code + headers + first part of MJPEG stream).
I can expose the camera on the Internet, please contact me.
The text was updated successfully, but these errors were encountered: