multer (1.4.1) hangs on malformed POST data

[jgresula]

Multer hangs on malformed POST data. To reproduce the problem just run this script against any multer enabled URL.

$ multer-hang.sh <any-multer-post-url>

The script uses a minimal real world payload produced by this IE bug.

[HarshithaKP]

@jgresula I was able to recreate the problem.
Server works fine (doesn't hang) - I tried connecting a healthy client from another terminal, and it returned response. Malformed client is hanging.

When I tried this client against plain express, it returns.

When Multer is involved, its middlewareFunction(s) do not seem to return the control to the user callback in the post router, and hence the hang.

@wesleytodd - any thoughts ?

[wesleytodd]

Hi @HarshithaKP, can you post your script as plain text here, or in a gist? I don't download random zip files, but would love to be able to help debug. thanks!

[HarshithaKP]

@wesleytodd here is the sample code.

Server.js :

var express = require ('express')
var app = express()
var multer = require ('multer')
var upload = multer({ dest: 'uploads/' })
app.post('/',upload.single('file1'), function(req, res){
        console.log('hey!')
        res.send('Saved the file, Thanks!')
});

app.get('/', (req,res) =>
{
res.sendFile(__dirname + '/index.html');
});
app.listen(8000); 

client :

curl -vk http://localhost:8000 \
     -H "Content-Type: multipart/form-data; boundary=--b--" \
     -H "Content-Length: 2612" \
     -X POST \
     --data-binary @- <<EOF
----b--
Content-Disposition: form-data; name="
----b----
EOF

Multer hangs when tried connecting with the above Malformed client.

[gireeshpunathil]

we (@HarshithaKP and I) did some further debugging on this and found the following:

• the server intercepts the request, and passes it onto to multer
• multer sets up the middleware function and delegate the control to busboy
• busboy reads the header, and establishes the necessary event handlers accordingly
• busboy pipes the request to itself. the intent is to continue reading the input (when it arrives), parse, and invoke associated handlers.

As the request is malformed (less data than it claimed), none of these preparations are used anytime - basically nothing happens.

• server goes on to listen for other requests
• client hangs, as it does not get response from server

the scenario will continue until one of the entity times out.

I see no issues here, other than the resources being held up at server for a duration that is longer than desired; but that is where the timeout tuning becomes important.

In short, my assessment is that things are working as designed; however, would love to hear from @wesleytodd or others. thanks!

[LinusU]

I agree with @gireeshpunathil assessment!

Basically we cannot really do anything else then waiting for the timeout if the client says "I'm going to send you 2000 bytes", then only sends 100 bytes...

happy to reopen if more information surfaces!