Plupload feature explanation
February 11th, 2010 by 
Afraithe We have gotten a few questions regarding the supported features of Plupload and what they mean exactly.
Chunking
Chunking is smart, it will allow you to upload files regardless of how large they are. Normally server environments have a limitation how much they can store in memory, normal upload forms put everything in memory and dumps it down when the whole file is received. With chunking, you can continue to upload even if the memory has a low limit cause the file is chunked into smaller parts and saved every x kilobytes.
PNG and JPEG resizing
Support for resizing means that images can be resized by the client, before they are uploaded to the server, saving a lot of bandwidth. Lets say you are uploading your vacation photos, instead of uploading a 2560×1600 image it will be resized down to a more web-suitable 640×480 image, saving a lot of space and making the upload quicker. Also this will use the client browser to resize the image and not the server resources.
Type Filtering
By type filtering we simply mean the option to select only a certain type of files, such as only .jpg etc.
Drag & Drop
This feature has been limited to Java Applets for so long now, but support for Drag & Drop is starting to look better in more of these supported ways to upload and we will continue to monitor their progress.
Fallback
A good approach when setting up Plupload is to configure your runtimes as optimal as possible, we would recommend the following order of fallback.
- Google Gears (best feature support)
- Silverlight (good support)
- Browserplus (good support)
- Flash (good support, best client spread)
- html5 (bad support, bad client spread)
Once html5 becomes more spread and usable, we would suggest putting it on top.
Why Flash so far down? Well actually after Google Gears (our personal favorite) the other plugins all have their faults and are rather similar. If chunking is required for you, remove HTML5 and Browserplus from the runtimes since they do not have support for chunking.
There are a few more options/features but they are quite simple and you should be able to figure them out if you check the documentation.
On another note, we will be making an update sometime soon with better buttons for uploading, a lot of ppl seemed to have missed the little “Play/Upload” icon on the right side of the UI and clicked the grey form send button instead.
If you want to contribute, be sure to visit the project on GitHub.
Posted in Cool stuff, Development, Software, Work
I’ve almost finished my custom implementation of plupload and its brilliant, really easy to work with.
I hope to contribute an ‘iframe’ runtime soon (the ultimate fallback). It doesn’t do anything special like the others, but can fake multiple file uplaods with a normal file input element.
February 11th, 2010 at 18:17That sounds very nice. I guess one needs some special tricks to get that working correctly. Have done similar tricks in the past.
Fork it on github and send a pull request to me and I will check it out. Thanks.
February 11th, 2010 at 19:00This looks like a great tool.
February 12th, 2010 at 10:55Hopefully the HTML5 support will broaden shortly (Chrome 5 support those and I think Opera 10.5 as well).
i love your plugin, but I would love to see an integration sample for asp.net for the upload.php script.
could you help me get that?
February 12th, 2010 at 12:47thanks
You may be interested in some of the research I’ve done with Flash with regard to client size file re-sizing and uploading. http://shift8creative.com/posts/view/flash-2176-security-woes
One thing that I always looked for with an uploader (swfupload, and many others) was the ability to not only have it resize, but allow for other form items on the page…Meaning I’m not dumping someone to a file upload page…The file upload is only a small part of the form on the page. So I want other normal form items mixed in with the upload element. Then that means a normal form submit button. That’s a big problem with Flash now because of a security issue. But I fixed that =)
This project looks real nice – the amount of options are great!
February 12th, 2010 at 18:51@peter: We will soon add examples for more backends and .NET is on the top of the list.
@Tom: Hmm, we didn’t have any security issues when posting the actual contents to the server using external interface. But browsing for files with out a click event isn’t possible in flash or silverligt and we work around that by using a shim. Don’t know if I missed some vital point in your blog post so feel free to enlighten me.
February 13th, 2010 at 00:21Because your content-type is application/octet-stream and not multipart/form-data.
February 13th, 2010 at 00:59I guess you are referring to the known cookie bug with the flash upload API. This is the only issue we had with using multipart but it was serios enought that we felt we needed to work around it. But we havn’t had any issues with posting using an external interface call so that must be something in your implementation or a very new flash security thing. But I fail to see why they would do that.
February 13th, 2010 at 10:29Not a cookie bug. http://jessewarden.com/2008/10/flash-player-10-surprise-error-2176.html
The error is 2176 it not only deals with the “browse” for file button / file attachment issue you know about but also when calling load() on a multipart form sending across file data.
Multipart requests work with external interface, but not when you send files. So if you’re going to mix sending file data and other serialized form data, you will run into this issue. I don’t know the scope or intent of pupload, maybe it’s never supposed to be combined on a page with other form input. Maybe it’s strictly just intended to allow people to upload files to some directory.
Unless you can somehow send some other form data along with what you’re sending/how you’re sending now. Which is something I didn’t investigate (of all the things) – I’m not sure how you can do that though. I guess the way you’re kinda doing that now is when you’re hanging on to what files go with what by passing variables via GET…but that isn’t going to work for all form data because of size limits.
Check out the links in my blog post because there’s a bit of information on this whole subject of file/form uploading with Flash. There isn’t much info, it took me a while to dig up, but it’s there.
The thing with sending one file, multiple files, or chunks of files over and over to one handler script is that it’s difficult for use in a practical application. Sending just a file w/o any reference is not the cleanest or easiest to embed. So the uploader itself is driving and dictating not only end user work flow, but also how the application must be built.
Also, look into a better encoder. The quality on the images render them nearly unusable.
If I had some time (and I may get some) I’ll see about forking from github. I don’t have multiple file handling (or in chunks) with the little uploader I built real quick and it’s a pretty sweet feature.
February 13th, 2010 at 22:00Hi, I have just find this great tool via O’Reilly reader insight.
That is really great. I have been looking for such tool for a long time, now it is arrived in the best way I could imagine.
Thank you guys.
And about these new flash security, it has just corrupted many sites from serving their older content correctly, I really don’t know why they don’t know anything about backward compatibility. I have been engaged with Flash since 2002 but recently I am very confused of. So, may be its time to slightly shift to Silver Light, huh?
February 14th, 2010 at 00:10Hi
wow, this one is great, after I had to dump swfupload because of lack of chunking and jfileuploader because java apllets seem to randomly crash many browsers (firefox as well as IE)
I added email-after-upload functionality to the server part.
What I am currently missing is recovering failed uploads. If sending huge files (gigabytes…) and the upload aborts, there should be a possibility to continue the upload. Some functionality to ask the server how much of the file is already there and then the client could just seek and send only the remaining chunks.
February 14th, 2010 at 16:32How do I prevent two parallel chunked uploads to get mixed up? There doesn’t seem to be a mechanism to make sure which received chunks belong together. Or am I missing something.
February 15th, 2010 at 19:17@Tom: Don’t see a upload issue. Just implemented multipart support in Flash. Might add the possibility to have mutltipart data parameters as well.
@Vahid: The security isse could be avoided by simply asking the user if a site can have access to upload. BrowserPlus uses this method and it’s both secure and better for users and developers.
@Gunstick: We have had plans for resume support. But it would involve a pretty complex backend so we might add that as some extra example or similar.
@Michael Daum: Why do you need to upload things in parallel. Nothing will get mixed up since each chunk event will send out both the uploader instance and the file that is currently uploading and one uploader can not upload more than one file at a time.
February 16th, 2010 at 12:30@Spoke: well, things do happen in parallel on a web server. Uploading something in chunks is a transaction. I was hoping to see some kind of random token being sent over that identifies the transaction. So backend would collect all concurrent uploads in buckets hashed by transaction token til the last chunk was received and then moves files to their final destination on the server filesystem.
February 16th, 2010 at 14:14It generates unique file names for the upload. This is the unique token for the upload it’s virtually a GUID uses the time in milliseconds and 5 random numbers and a page counter. The next version will enable you to seed it as well.
February 16th, 2010 at 16:22Hm, the Uploader class itself? Am I blind?
February 16th, 2010 at 18:28Okay I see now. Thats done inside the pluploadSingle and pluploadQueue classes. I don’t think creating a unique filename like this is a viable solution as the real filename is lost then. In fact, the guid should be transmitted as part of the chunkArgs logic as that’s what it is used for – assembling the bits again inside the Uploader class.
February 16th, 2010 at 19:07Hi !
Thank you for releasing this great project ! everybody was looking for something like this until now !
I have been experiencing some problems with Apache while upload ing big file (~150mb) : “child pid 9688 exit signal Segmentation fault (11)”. Which http server are you using ?
Here is my vhost conf :
php_admin_value post_max_size 750M
php_admin_value upload_max_filesize 750M
max_execution_time 600
do I need something else ?
Thanks !
February 16th, 2010 at 20:59@Michael: The original file name is intact since it’s passed in a separate parameter once you post the form. So there is currently no issues with the Queue Widget and chunking from multiple users. It will generate an unique file name, add the chunks to that unique file name and then when it’s finished post the form with the temporary file name and the real file name. If you need to have more control you can just make your custom upload implementation using the low level API and add an post unique key to the url parameter like url : ‘somepage.php?uniquekey=something’.
@ArnaudD: I suggest using chunking with a 10MB size. Uploading huge files to PHP will allocate lots and lots of RAM and probably produce a seg fault. We added chunking support for handling of huge files like this.
February 16th, 2010 at 21:58@Spocke: removing xdebug and apc extensions resolved the segfault error, but upload.php doesn’t seems to be interpreted although there is traces of a POST request in access.log. I’m encontering this problem in 2 different system conf (ubuntu 8.10 & 9.10). I must have missed something.
February 17th, 2010 at 12:23I found some explanations for my problem : I had to push php memory_limit from 120M to 900M to be able to upload a 270M file with the html5 runtime because there is no chunking. BTW, according to php:memory_get_usage(), sending the file with chrome took 850M and was correctly written to the disk, while firefox took 450M but only 16M was put on disk. I’ll try to dig into this.
Is it possible to use $_FILE instead of php://input ?
February 17th, 2010 at 17:34The HTML5 runtime allocates the total file size in RAM on the client machine as well. This is a browser limitation and hard to avoid but hopefully they will implement a blob API similar to the one Google gears uses then it will be smooth to work with.
We have just added basic multipart support for most runtimes in the GitHub repos. However WebKit can’t upload files this way at the moment so it still needs a php://input stream. But we will document and add these to the feature grid.
February 17th, 2010 at 18:31Hey Spocke,
We released FileAccess v 2.0.x yesterday which provides a couple of file chunking apis: http://browserpl.us/docs/services/FileAccess.html
Please give these apis a try and let us know how
things work out.
lloyd (of BrowserPlus)
February 17th, 2010 at 19:10Ok, thank you for your help !
February 17th, 2010 at 20:08@Lloyd Hilaiel: Wow you guys where fast in implementing that. The API looks perfect, will try it out tomorrow. Will also report those bugs I found.
February 17th, 2010 at 20:37Still intrigued by the seemingly lack of security issues on the Adobe 2176 security with regard to multi-part data and files… I have to take a double look at what you’re doing. In the meantime, I’ve posted my little project which may be of interest to you for ideas and what not. http://www.shift8creative.com/projects/agile-uploader/index.html
It turns out that there are some other benefits to base64 encoding…Such as the fact you can send image data as base64 to JavaScript so your preview lists can include thumbnails and not just text (where you currently have file names and sizes). However you should note that this isn’t supported in IE6. I think a pretty sweet addition though for your tool.
February 19th, 2010 at 20:11Is anyone else having problems getting Plupload working??? I love it and really want to use it but it won’t work for me. I got the examples as is on my server, created the tmp directory but the examples wont work and there is no errors displayed in the GUI.
Is there going to be a forum for Plupload???
February 23rd, 2010 at 07:29@Steve We are looking into making more examples and documentation on how to get started with Plupload, there isn’t currently any Forum, we use Github to track bug reports for now though.
I would suggest using Fiddler to debug the communication between Plupload and the server script.
February 23rd, 2010 at 12:00Amazing project, keep up the good work guys. Will a parameter for limiting the user to a single upload rather then a multiple file upload be available in future release?
February 26th, 2010 at 14:19We used to have such a feature but it’s currently not tested and maintained. Will re-add it as an official part later on since it might be useful for more simple forms.
February 26th, 2010 at 19:56