Hacker News Reader

Comment by alecco | Hacker News Reader

Browser HTTP file upload is still terrible for file transfer. One of the last bastions of Flash, regretfully.

Browsers are terrible at file upload. The weakness here isn't really in the protocol.

That's why I said browsers. But only recently with HTML5 XHR file uploads we could have progress and status reported in-page (instead of poorly in the status bar, if any). And it's still not good enough and definitely not widely available.

But the choice isn't between "browsers doing FTP" and "browsers doing HTTP"; it's between special-purpose FTP software and (somewhat hypothetical, if you exclude Transmit) special-purpose HTTP software.

Huh? As long as you have XHR and JS, you can do file upload progress bars. Gmail has been doing it for years, and I've certainly had implementations going back to 2007.

Now, if the upload is failed for whatever reason (i.e. the file is rejected in-progress), then the upload failure mode is terrible unless you resort to the usual iframe hackery (Connection Reset screen).

HTML5 XHR file upload is certainly a cleaner solution and something everybody has wanted, but it's certainly not needed for progress and status reported in-page without flash.

OK.

Small nitpick, Gmail used a Flash uploader for many years, at least until 2009:

http://ajaxian.com/archives/multi-file-upload-in-the-flickr-...

Uh, yeah, you needed flash. You can't read local files in javascript without the HTML5 file api. Reading the value of <input type='file'> tags is forbidden in javascript. Try it.

axiak is right, I've done this myself too. The server can read the file size during transfer and send this back to the client over XHR. It's quite messy to set up and most backend frameworks require obscure hacking (reflection in asp.net for example) to get it to work, but it certainly is possible.

XHR is awful for large file uploads. It doesn't support sending the file object (which presumably would be processed according to RFC1867) on Firefox, but it does support that on Chrome.

As a result, for cross-browser compatibility you have to upload via raw POST data and send your own file metadata headers. Not entirely a bad thing, but it's annoying because most HTTP servers don't support this. And because you cannot send the file object, you have to load the file into browser memory. No streaming options.

Thus, you have to make multiple request uploads that upload a chunk at a time to the server per request (spliced uploading), which is annoying and unnecessary.

To make matters worse, Chrome doesn't support XMLHttpRequest.sendAsBinary (WHY? you can easily implement this in javascript anyway), and a bunch of other random inconsistencies.

And no, PUT doesn't help.

Huh? You mean the same Flash that can't display a list of paths to local user files to the user for "security reasons" so the user can do batch uploads? I agree with the sibling comment, browser-based file upload sucks.

Reply on news.ycombinator.com