Restrict File Size Limit While Choosing File

[sffc]

Restrict File Size Limit While Choosing File

[usar-naem]

I would like to +1 this request. It should not rely only on the client filter. The server needs to reject files larger than the specified amount, and make sure the final size is the same as announced at the start. Filtering by extension is good too.

Currently the behavior for submitting a 20mb+ file is an empty file being created, and the server hanging indefinitely thereafter. The only way this is viable in a production environment is if you can force a maximum size with 100% certainty.

I would lend my hand, but I fear I may not be up to the task.

[vote539]

Yeah, you're right. This feature should really be supported in this module. I'll look into it.

[vote539]

My latest commit adds support for file size checking. Let me know if the API and such looks good to you. If it does then I'll go ahead and push it out to npm.

[usar-naem]

Well it's not impenetrable, but the "saved" event is now rather inaccurately named. I would suggest adding an error code for straight up upload failure as well, and dropping the success flag. "Saved" should be reserved for success cases only, or renamed appropriately. Handling file rejection out of the "error" event seems fine to me.

[vote539]

Well it's not impenetrable

Can you explain?

but the "saved" event is now rather inaccurately named. I would suggest adding an error code for straight up upload failure as well, and dropping the success flag. "Saved" should be reserved for success cases only, or renamed appropriately. Handling file rejection out of the "error" event seems fine to me.

The "error" event is fired when file upload is large. An empty file is always created on the filesystem, so it seems to me like "saved" is a fine event name. An application can always check for event.file.success for whether or not the save was successful. Renaming the event is not an option due to backwards compatibility, which I put as a high priority.

[usar-naem]

By not impenetrable, I simply meant that it's not difficult to understand. :)

Are you sure you want an empty file to be created if the server intends to reject the upload? I think the logical behavior is that you want to stop the process as soon as you know that you don't want the file, so as not to even bother the file system with useless tasks.

EDIT: Oh, I understand. In an ideal world, you would be writing to the file one part at a time, not buffering it. Your api makes sense now.

[vote539]

The client could tell the server ahead of time how big to make the file, and if the file exceeds the bounds then the server can ignore it. However, this depends on the client telling the truth about the size of the file, and if the client is telling the truth, then they won't even send a request to the server in the first place due to the client-side validation in 5ff8e73.

I'll run a few more manual tests and then push this out to npm. One of these days I'll need to set up automated testing for this module (or merge a pull request that does it). 😃

[pitambar]

thank you for implementing the requirement :)

[vote539]

This change has been published to npm in versions 0.3.1 and higher.