I have noticed that the new XMLHttpRequest object supports an 'onprogress' event in firefox. Is it possible to utilize part of the new HTML5 File api's to get an upload progress bar without any server-side modifications required?
I believe in principle yes, though I haven't tried it out yet.
What's going to be a problem is that XMLHttpRequest#send() takes a Unicode string and encodes it as UTF-8. It doesn't give you the ability to send pure binary, and most binary files like images are not going to happen to be valid UTF-8 sequences.
So probably you'd be using what the FileAPI spec calls a “binary string” (bytes treated as ISO-8859-1, so each charCodeAt corresponds to a byte), recoded to UTF-8. This would end up around 50% bigger than a plain file upload. Is it worth the slower upload to get the progress report?
(God, if only browsers had a better UI to show how the upload was going, none of the endless scripting/Flash/Java/ActiveX nonsense would ever have been necessary. Come on, browser vendors, is a nice big info popup with a progress bar really too much to ask for?)
Yes, in theory, although I would have to question the accuracy since Internet speed generally fluctuates (more-so if you aren't wired). It would probably jump around alot.
Then again, what is an accurate progress bar? I'd like to see one in Windows before I see one online!
Related
I'm facing an interesting problem right now: I want to modify a PDF file generated on the server (using TCPDF and Symfony2) on the client before displaying it.
Why? The PDF will contain some semi-sensitive information and our customers would probably be happy to hear that this info never leaves their machines. (I'm aware that HTTPS is considered pretty much safe enough, this is more of a luxury issue to assure our customers that their data is safe.)
This is how far I got: Use placeholders on the PDF, save it as a String and retrieve it via AJAX, replace the placeholders with the local data, and convert the string to Base64. The real issue is getting the file to the user.
A lot of people recommend using the HTML5 "download" Attribute and clicking a hidden link with it, that method does not work on Safari or older versions of IE though. Data URIs are another option, but beyond a certain complexity the base64 string just gets too long and the browser freezes trying to display it in the address field. I also looked at libraries like Downloadify.js, FileSaver.js etc. but none of these seem widely supported (or rely on flash, which I would love to avoid).
I'm very open to suggestions as to what else I could try, or even someone telling me why what I'm trying to do is wholly unnecessary.
This question already has answers here:
jQuery or javascript to find memory usage of page
(10 answers)
Closed 8 years ago.
I have website which can upload images.
I do CROP from client side before upload then in server side new optimize...
On Mobile devices when no Free RAM fails.
How I can get RAM memory usage from JavaScript to skip CROP if there no memory?
I am looking only JavaScript solution!.
PLEASE I do not have LEAK OF MEMORY!!!
if I open many apps and no much RAM left my strategy not working
I need CODE by JavaScript get the free RAM and if is it bellow some amount I skip the CROP
------------ OK define Fail: --------------
From mobile devices people take photo and upload it...
from JavaScript I perform CROP
1. around 2MB image goes to 300kb
2. I upload only 300kb then from server side 300kb --> 30kb that I save
If there is no RAM this FAILs
I do not want to say "try again"
I would like to Skip the CROP
Thank you very much for comments.
I handle the errors but I would like to avoid client to wait 40-60 sec and then message
If I go with NO CROP IS IT OK but saving near 1.7MB per image bandwidth... GREEDY :-)
window.performance good I will used thanks.
I will do research to have round trip from SERVER SIDE what I can do can I find it for Mobile devices
In Development
Use Chrome's DevTools for pretty comphrensive diagnostics. You can get JavaScript run-time diagnostics, request information, and basically anything you might need.
Client-side Testing
As far as testing how much RAM is available in your code itself, there isn't really a "correct" or "recommended" strategy (source). Obviously the best solution would be to just optimize your code; varying your site's display/interactions based of how many other apps a client is running could be confusing for the user (eg: they expect some tool to be displayed and it never is; they think the page isn't loading properly, so they leave; etc.).
Some highlights from the source above:
"Counting DOM elements or document size might be a good estimation, but it could be quite inaccurate since it wouldn't include event binding, data(), plugins, and other in-memory data structures."
You'll need to monitor both the DOM and the memory you're using for your code for accurate results.
You could try using window.performance (source), but this isn't well-supported across different browsers.
Note: As Danny mentions in a comment below, showing an advisory message when a feature is disabled could clear up some confusion, but then why use the resources on a feature that is so optional that you could just not use it? Just my two cents... :)
On a webpage, is it possible to split large files into chunks before the file is uploaded to the server? For example, split a 10MB file into 1MB chunks, and upload one chunk at a time while showing a progress bar?
It sounds like JavaScript doesn't have any file manipulation abilities, but what about Flash and Java applets?
This would need to work in IE6+, Firefox and Chrome. Update: forgot to mention that (a) we are using Grails and (b) this needs to run over https.
You can try Plupload. It can be configured to check whatever runtime is available on users side, be it - Flash, Silverlight, HTML5, Gears, etc, and use whichever satisfies required features first. Among other things it supports image resizing (on users side, preserving EXIF data(!)), stream and multipart upload, and chunking. Files can be chunked on users side, and sent to a server-side handler chunk-by-chunk (requires some additional care on server), so that big files can be uploaded to a server having max filesize limit set to a value much lower then their size, for example. And more.
Some runtimes support https I believe, some need testing. Anyway, developers on there are quite responsive these days. So you might at least try ;)
The only option I know of that would allow this would be a signed Java applet.
Unsigned applets and Flash movies have no filesystem access, so they wouldn't be able to read the file data. Flash is able to upload files, but most of that is handled by the built-in Flash implementation and from what I remember the file contents would never be exposed to your code.
There is no JavaScript solution for that selection of browsers. There is the File API but whilst it works in newer Firefox and Chrome versions it's not going to happen in IE (no sign of it in IE9 betas yet either).
In any case, reading the file locally and uploading it via XMLHttpRequest is inefficient because XMLHttpRequest does not have the ability to send pure binary, only Unicode text. You can encode binary into text using base-64 (or, if you are really dedicated, a custom 7-bit encoding of your own) but this will be less efficient than a normal file upload.
You can certainly do uploads with Flash (see SWFUpload et al), or even Java if you must (Jumploader... I wouldn't bother, these days, though, as Flash prevalence is very high and the Java plugin continues to decline). You won't necessarily get the low-level control to split into chunks, but do you really need that? What for?
Another possible approach is to use a standard HTML file upload field, and when submit occurs set an interval call to poll the server with XMLHttpRequest, asking it how far the file upload is coming along. This requires a bit of work on the server end to store the current upload progress in the session or database, so another request can read it. It also means using a form parsing library that gives you progress callback, which most standard language built-in ones like PHP's don't.
Whatever you do, take a ‘progressive enhancement’ approach, allowing browsers with no support to fall back to a plain HTML upload. Browsers do typically have an upload progress bar for HTML file uploads, it just tends to be small and easily missed.
Do you specifically need it two be in X chunks? Or are you trying to solve the problems cause by uploading large files? (e.g. can't restart an upload on the client side, server side crashes when the entire file is uploaded and held in memory all at once)
Search for streaming upload components. It depends on what technologies you are working with as to which component you will prefer jsp, asp.net, etc.
http://krystalware.com/Products/SlickUpload/ This one is a server side product
Here are some more pointers to various uploaders http://weblogs.asp.net/jgalloway/archive/2008/01/08/large-file-uploads-in-asp-net.aspx
some try to manage memory on the server,e.g. so the entire huge file isn´t in memory at one time, some try to manage the client side experience.
The project is a servlet to which people can upload files via, at present, HTTP POST. This is accompanied by Web page(s) providing a front-end to trigger the upload. We have more or less complete control over the servlet, and the Web pages, but don't want to impose any restrictions on the client beyond being a reasonably modern browser with Javascript. No Java applets etc.
Files may potentially be large, and a possible use case is mobile devices on less reliable networks. Some people on the project are demanding the ability to resume an upload if the network connection goes down. I don't think this is possible with plain HTTP and Javascript in a browser, but I'd love to be proved wrong.
Any suggestions?
Not with Plain Ol' JS. It doesn't have access to the file system, not even a file added to an input type=file control and so it cannot manipulate the data and upload via XHR instead.
You would have to look into a Flash or Java based alternative.
With your current restrictions, no.
(There may be a tiny chance that using the HTML5 file api could be capable of doing this. Maybe someone more knowledgeable can comment because I usually cannot make heads or tails of technical specifications from the w3c : http://www.w3.org/TR/file-upload/ )
Firefox 3.6 implements a FileReader interface, however it doesn't seem to support any form of skipping. Therefor, you would need to read the file and split it where you need it to resume.
This would not be especially useful for large file since you would probably crash the browser anyway because of the memory-allocation it would need.
https://developer.mozilla.org/en/DOM/FileReader
I am working on a web application that will deal with many image uploads. Its quite likely that the users will be in areas with slow internet connections and I'm hoping to save them upload time by compressing the images before uploading.
I have seen that Aurigma Image Uploader achieves this using a java applet or active x but it's expensive and I'd rather something open source or at least a little cheaper. Ideally I'd like to roll my own if its at all possible.
I'm developing on Ruby on Rails if that makes any difference..
Thanks!
Edit just to clarify: I don't mind if the solution uses activeX or an applet (although js is ideal) - I'm just looking for something a little cheaper than Aurigma at this stage of development.
Also, it may not be feasible for users to shrink the image themselves as in many instances they will uploading directly from an internet cafe or other public internet spot.
Generally, it isn't possible to write an image compressor in JavaScript. Sorry.
You'll need to use a plugin of some sort, and as you mention, other sites use Java.
It appears to be possible to write something to encode a JPEG in ActionScript (i.e. Flash), which will reach a much larger audience than the Java plugin you mention. Here's a link to a blog post talking about PNG & JPEG encoders in ActionScript.
Here's another blog post with a demo of an inlined JPEG encoder in ActionScript.
Only if you use Flash or Silverlight (only way to be cross-platform)
http://www.jeff.wilcox.name/2008/07/fjcore-source/ may be worth a read.
Without using applets or activex (only in windows) you can't execute anything on a client pc.
Probably not, but you can always insist that image uploads over x size will not succeed.
Is this an application where you can force them to insert a smaller image. In that case you could grab the size first to verify it fits standards. This is what facebook used to do with profile pictures. If it was too big they wouldn't take it.