Forms with enctype="multipart/form-data" cause Kraken to time out and abort processing

[mykemorgan]

Summary

Forms with enctype="multipart/form-data" cause Kraken to time out and abort processing

Basically, the form data never arrives to middleware downstream from the multipart middleware which should be parsing the input.

A generic example button form which causes the problem:

<form method=post action="http://localhost:8000/my-app" enctype="multipart/form-data">
  <input type=hidden name=cmd value=my_command>
  <input type=hidden name=email value="test@test.com">
  <input type=hidden name=item_name value="Multipart Item">
  <input type=hidden name=item_number value="1234">
  <input type=submit value="Multipart 01">
</form>

The actual business logic does not seem to matter, since it fails before getting to any of it.

Details / Analysis done

Please bear with me, as this is my first time debugging kraken-js "internals". Let me know if more info is needed.

The error seems to be a timeout in the formidable package included from kraken-js and used in KRAKEN/middleware/multipart. This package is what reads incoming text and parses it into the sent form parameters. This is all happening before it gets to my custom middleware where my application logic resides (which makes sense due to the priority ordering), so I believe it's a generic framework issue.

Seems like the header is being sent with the correct number of bytes, and the form data from the browser is coming in as part of the request.rawBody. It finds the correct delimiter from the headers (----WebKitFormBoundaryv3V6OuoBrj9W2uXs--) so it seems all ready to start parsing. But there is no incoming file to parse since all the data has already arrived.

I am getting this abort/timeout error:

[2017-02-20 17:57:28.101] - error: unhandled_error:
{
  "error":"Error: Request aborted
	at IncomingMessage.<anonymous> (~/node_modules/formidable/lib/incoming_form.js:120:19)
	at emitNone (events.js:67:13)
	at IncomingMessage.emit (events.js:166:7)
	at abortIncoming (_http_server.js:280:11)
	at Socket.socketOnEnd (_http_server.js:425:7)
	at emitNone (events.js:72:20)
	at Socket.emit (events.js:166:7)
	at endReadableNT (_stream_readable.js:905:12)
	at ~/node_modules/async-listener/glue.js:188:31
	at nextTickCallbackWith2Args (node.js:437:9)
	at process._tickDomainCallback (node.js:392:17)
	at process.fallback (~/node_modules/async-listener/index.js:482:15)",
}

Here's the request payload from the above sample form which comes to the app in the req.rawBody:

------WebKitFormBoundaryv3V6OuoBrj9W2uXs
Content-Disposition: form-data; name="cmd"


my_command
------WebKitFormBoundaryv3V6OuoBrj9W2uXs
Content-Disposition: form-data; name="email"

test@test.com
------WebKitFormBoundaryv3V6OuoBrj9W2uXs
Content-Disposition: form-data; name="item_name"

Multipart Item
------WebKitFormBoundaryv3V6OuoBrj9W2uXs
Content-Disposition: form-data; name="item_number"

1234
------WebKitFormBoundaryv3V6OuoBrj9W2uXs--

What I've gotten to so far is:

It seems like the header is received with the correct number of bytes for the payload, and the form data from the browser is coming in as part of the request.rawBody. All fine so far. The multipart/formidable middleware finds the correct delimiter in the request headers (----WebKitFormBoundaryv3V6OuoBrj9W2uXs--) so it seems all ready to start parsing.

At this point my guesses are:

• The issue is around that there is no incoming file to parse since all the data has already arrived. There is nothing in req.file
• Maybe formidable streams were set up after the data got sent so it's never seeing the data?
• Maybe somehow when kraken gets the multipart encoding it assumes a file is incoming and ignores what was in the request body?

[shaunwarman]

Hey @mykemorgan - thanks for the write up!

I created a simple vanilla kraken app to test formidable form handling. Take a look here.

It looks like I am getting the following in req.body:

Form data: {"cmd":"my_command","email":"test@test.com","item_name":"Multipart Item","item_number":"1234"}

I assume the webkit information is coming from somewhere else. Let me do some searching for why this webkit info is coming in.

[mykemorgan]

ACK'ing that this looks like it works properly for a basic kraken app. whew!

Our actual app has a fairly custom middleware chain that might be interfering with the multipart parsing. With @shaunwarman's help we've likely narrowed down the issue to that (since the simple server he linked to above works fine). Will update when I get to the root of our problem, or you can close this issue, either way.

[shaunwarman]

Thank's @mykemorgan ! Will chat offline.