Archives Posts
Uploads via HTTP are still an issue…
Even in the days of Web 2.0 you encounter many errors when it comes to Uploads via HTTP. The protocol was never made for uploads or better to say: there are still enough bugs in implementations and the protocol itself.
Very familar, e.g. is the problem of having a meter on upload progress. And i also don’t want to mention the problems of WebDAV implementation of Windows for now, or the limitations of firewalls or proxies…
But let’s have a look on solutions provided today in the Web for Uploads…
Flash/HTTP
We have a modified version of R6 running on a webshop with regular uploads of 20-70MB files. If upload goes to fast – like on business lines with upstream ≥3Mb – Flash is likely to throw errors telling the visitor a script is running too slow. Then the customer has to choose „continue“ or to „cancel“, which usually ends up in canceling the job 
This behavior is caused by Flash calling the „onFileChunkComplete“-Event (or something) too often, or let’s say after every 4096 bytes sent, which can result in many many calls if you have a good upstream bandwidth.
Second, there are also those „unknown errors“ in Flash caused at runtime. The source yet is unknown and it seems to continue with Flash10 and some little amount of customers smaller than one percent share. Sorry, unknown means unknown and Adobe won’t give support here! we’re back to Flash9 
Yet the same thing happens to JavaScript if update goes too fast and too often, e.g. by using a progress bar constantly being updated (20-50times in the second). Therefore I had to split up the graphical update process to a seperate class that just goes on update intervals calling the current/total-values of the FileUpload-Class.
Well using Flash as upload client is nice, especially with the ability to use real sockets. For Flash9 the HTTP methods don’t provide the possibility of splitting large files – so you could upload them in seperate chunks. It’s about security.
Then Flash10 possibly could do now (by accepting local files), but here we have the issue of having the upload beeing fired from Flash itself – scripting doesn’t work anymore, so no hidden flash uploader, that could do the job 
But customer complaints still continues… especially form those using MSIE and don’t get a thing right.
PHP and APC, for now. HTTP again…
Okay, usually you gotta think this works now. It’s out now for long enough. But fail of proof!
I leeched some script form PHPRiot yesterday by Quentin Zervaas, fixed some bugs (while(1=1) is great idea in JavaScript 
), added a file limit check and hoped i finally would have something that really works. But it didn’t:
- Multiple file-fields do not work with APC
- If file uploaded is greater than far greater than limit, apc throws out 0-values for current and total
- Sometimes just seems stop working somehow; but after an apache restart apache it works again
I tried so many ‘solutions’ now and somehow it really seems to me, that monitoring the upload by calling a server-side status-script always has some problems. Probably it is really an Apache-issue… we’ll have too see…
Sliced HTTP Upload via Plugins – a solution?
I already mentioned it in the Flash/HTTP section, and indeed it’s more safe, because the file chunks are simply smaller!
I did many tests with Apache, and often it just happens that Apache closes a TCP connection on big file uploads. The source is yet unknown to me. Probably it has to do with Apache itself. I didn’t encounter the problem when using FastCGI and a Perl-Script to handle my upload.
So, i guess doing sliced upload is a good option. But then you could only use Flash10 which has other restrictions or Java. Yep, that thing that only works on 70-80% of user browsers, MSIE for the rest that reports about having Java supported – true indeed – the other problem is: does it really run on those often misconfigured and compromised customer systems?
Well Flash10 now does, but have some limitations we probably could live with:
- load() and save() APIs can only be called in response to user interaction (such as a button click).
- locations of the loaded and save files are not exposed to ActionScript.
Since the API is now asynchronous (non-blocking),
Final match: HTTP vs. FTP-Uploads in the client
- HTTP was not made for upload!
- use more bandwidth than you actually need (base64!)
- HTTP is not resumeable (but you could retry on splitted chunks)
Let’s summariuze: You can only monitor what was uplaoded by having control over your client and you can only split files, when you have access on it.
Use a Java-Applet or code a Flash-Client that works over FTP! And use a FTP-Server that is secure and can handle virtual users, like vsftpd. Then code some backend,
Yes! Probably it is a solution. But you still have the problems with users not supperting Java, or who complain about Java „loading“ too long. Here are some other good tries, that usually work:
- http://www.aurigma.com/
- http://www.jupload.biz/
- http://www.javaatwork.com/
- http://upload.thinfile.com/
We’ll see further when the first FTP libraries for Flash 10 are finished.
I just everyone who uses DOJO is also using it, otherwise I am gonig to hate your websites!
If you look at todays web 2.0 sites you will realize there is often a heavy load on external JavaScript resources, CSS files and probably images. Above compressing and optimizing the files and merging multiple files (also background-images), there is not much room to further optimize the page loading process.