ECONNRESET received when sending payload larger than content-length header

[hueniverse]

This is new behavior in 0.10. In 0.8 it just truncated the incoming payload to the specified content length. Is this intentional?

var http = require('http');

var server = http.createServer(function (req, res) {

    var payload = '';

    req.setEncoding('utf8');
    req.on('data', function (chunk) {

        payload += chunk;
    });

    req.on('end', function () {

        res.writeHead(200, { 'Content-Type': 'text/plain' });
        res.end(payload);
    });
});

server.listen(8000);

var req = http.request({
    hostname: 'localhost',
    port: 8000,
    path: '/',
    method: 'POST',
    headers: {
        'Content-Length': 1
    }
},
function (res) {

    res.setEncoding('utf8');
    var payload = '';
    res.on('data', function (chunk) {

        payload += chunk;
    });

    res.on('end', function () {

        console.log('Reply: ' + payload);
    });
});

req.on('error', function (err) {

    console.log(err);
});

req.write('hello');
req.end();

[isaacs]

Well, in 0.8, it'd completely ignore ECONNRESET in many cases, which is pretty much the worst possible thing to do. So, yes, this is by design.

[hueniverse]

Update the code to run on both 0.8 and 0.10.

@isaacs but why does this return ECONNRESET? the server side gets a valid payload and is able to send a reply. Somewhere later the connection resets.

[hueniverse]

In other words, I'm trying to find a way for the server to figure out there is a problem. Right now the only place where an error is emitted is on the client. The server sees the partial data and replies, but somewhere in node the connection is dropped.

[bnoordhuis]

The http.Server object emits a clientError event with (err, socket) as the arguments. In this case the error will probably be HPE_INVALID_METHOD or HPE_INVALID_EOF_STATE, depending on whether keep-alive is enabled.

[hueniverse]

@bnoordhuis Thanks.

[hueniverse]

BTW, the odd thing about this new behavior is that node is dumping the request but is still passing it to the server's callback, and the clientError is not tied to the incoming req/res pair. So basically, the server is going to do all this work creating a response that no one is going to receive.

Is there a clean way to chance the code above so that the server will abort processing this request?

[bnoordhuis]

the server is going to do all this work creating a response that no one is going to receive.

That's not quite correct (and it's something you can verify with e.g. curl). The reason node closes the connection is that it's impossible to correctly parse the next request but there's nothing stopping it from responding to the current one.