How to cancel user upload in Formidable (Node.js)?

I will attempt to answer my own question...

So after some trial and error with Formidable, I simply gave up on it and switched over to Multiparty. Multiparty ACTUALLY cancels the upload when an error is emitted which was huge.

My Solution

So my solution utilizes client-side size and type checking (not shown in code). The request is then sent to the server. At the server, I check again if the file size and type are correct BEFORE WRITING TO DISK. I am able to do this by using Multiparty's part event. If they are not correct then I simply send a response with a 413 error. (Thanks to josh3736 for clarifying what is supposed to happen in the browser.) After sending back a 413, the behavior of the browser is a little sporadic. For the browser that I was testing in, it just showed a pending post request. I believe this behavior is due to the fact that the entirety of the form has not be handled, therefore, it will not accept any responses. This may not seem like the most elegant way to deal with it since no error code is displayed, but this behavior will only be encountered by malicious users who bypass the client-side checking (my site is dependent on Javascript so all users will have it enabled if they want to use my site). So that is my solution in words, now for some code...

app.post('/profile/profile_pic', urlencoded, function (req, res) {    var path = absolutePath + '/public/images/users/' + req.session.userId + '/';    var maxSize = 3146000; // 3MB    var options = {uploadDir: path};    var form = new multiparty.Form();    form.on('error', function(message) {        res.status = 413;        res.send(413, 'Upload too large');        res.end();    });    form.on('file', function(name, file) {        var type = file.headers['content-type'];        type = type.split('/');        type = type[1];        fs.rename(file.path, path + 'profile.' + type);        path = '/images/users/' + req.session.userId + '/profile.' + type;    });    form.on('part', function(part) {        var type = part.headers['content-type'];        var size = part.byteCount - part.byteOffset;        if(type != 'image/jpeg' && type != 'image/png' && type != 'image/gif' != 'application/pdf' || size > maxSize)        {            this.emit('error');        }    });    form.on('close', function(){        res.json({err: 0, path: path});    });    form.parse(req);});

To abort the upload, the proper thing to do is close the socket.

req.socket.end();

Unfortunately, the situation where a server wants to abort an in-progress HTTP upload is a mess.

The proper, spec-compliant thing to do here is simply send a HTTP 413 response early – that is, as soon as you detect that the client has sent more bytes than you want to handle. It is up to you whether or not you terminate the socket after sending the error response. This is in line with RFC 2616. [...] What happens next is not ideal.

• If you leave the socket open, all browsers (Chrome 30, IE 10, Firefox 21) will keep sending data until the entire file is uploaded. Then and only then, the browser will display your error message. This really sucks since the user must wait for the entire file to complete the upload, only to find out the server rejected it. It also wastes your bandwidth.

  The browsers' current behavior is in violation of RFC 2616 § 8.2.2:

  An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty trailer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection.

  There are open Chrome and Firefox issues, but don't expect a fix any time soon.

• If you close the socket immediately after sending the HTTP 413 response, all browsers will obviously stop uploading immediately, but they currently show a "connection reset" error (or similar), not any HTML you might send in the response.

  Again, this is probably a violation of the spec (which allows the server to send a response early and close the connection), but I wouldn't expect browser fixes any time soon here either.

The fact you're seeing a loop of POST requests is suspect. Are you using some kind of AJAX uploader? It may be automatically retrying the upload after you close the socket early.

Some time has passed and now you can use multer instead of formidable or multiparty. Multer has desired functionality built in.