A 64-bit unsigned integer representing the total amount of work that the underlying process is in the progress of performing. When downloading a resource using HTTP, this is the Content-Length (the size of the body of the message), and doesn't include the headers and other overhead.
This would be useful to show a progress bar when the user is uploading a large file. The standard API doesn't seem to support it, but maybe there's some non-standard extension in any of the browsers out there? It seems like a pretty obvious feature to have after all, since the client knows how many bytes were uploaded/downloaded.
note: I'm aware of the "poll the server for progress" alternative (it's what I'm doing right now). the main problem with this (other than the complicated server-side code) is that typically, while uploading a big file, the user's connection is completely hosed, because most ISPs offer poor upstream. So making extra requests is not as responsive as I'd hoped. I was hoping there'd be a way (maybe non-standard) to get this information, which the browser has at all times.
For the bytes uploaded it is quite easy. Just monitor the xhr.upload.onprogress event. The browser knows the size of the files it has to upload and the size of the uploaded data, so it can provide the progress info.
A more efficient way would be to use flash. The flex component FileReference dispatchs periodically a 'progress' event holding the number of bytes already uploaded. If you need to stick with javascript, bridges are available between actionscript and javascript. The good news is that this work has been already done for you :)
On the clientside i have a File-Dropzone (HTML5 File-API) where the user can drop multiple files that should be uploaded to the server. For each file a new XMLHttpRequest Object is created and the file is sent asynchronously to the server. I'm monitoring the progress through a progress event Listener on the xhr.upload object.
The problem is, that as of now the server side needs to get the files synchronously because there is some calculation happening that must be done one file after another on the server-side and unfortunately i cannot change that implementation. But if i set the xhr object to send the files synchronously the function that i registered with the progress event will not fire anymore so i'm not able to monitor the progress.
I'm trying out the new XMLHTTPRequestUpload feature to upload some files to a php script, it mostly works fine, the upload starts, I get the finish response etc - but the progress doesn't seem to work.
The cause of the problem ended up being simple -- in Google Chrome (possibly other browsers too, I did not test), the progress event will only fire in succession if the upload had been running for a second or two. In other words, if your upload finishes quickly, then you'll likely just get one 100% progress event.
This behavior depends upon how fast your Internet connection is, so your mileage will vary. For example, if you take the first example and use Chrome Developer Tools to slow your connection to a simulated "Slow 3G", then you will see the series of progress events.
Similarly, if you are developing locally and uploading data to a local web server, you'll likely never see progress events because the upload will finish instantly. This is likely what @brettjonesdev was seeing in localhost vs remote prod deployments.
I have similar issue and I found reason. In my case the troublemaker is antivirus (bitdefender) on my PC. When I turn off bitdefender protection, the progress behaves exactly as it should.
I'm using XMLHttpRequest (with jQuery) to get the upload progress of multiple files. By adding a "progress" event listener to the XMLHttpRequest object I can get event.loaded and event.total. Those variables give me the loaded and total bytes of all the files combined.
When submitting requests to a server, you may want to know its progress, for example when uploading large files which can time.Several approaches can be taken for monitoring both the upload and download progress, with this post showing two different methods.Towards the end of the post, it will show how to use these different methods with jQuery, and discuss further steps that can be taken.
While using EventTarget to attach a listener is fine, XHR also inherits from XMLHttpRequestEventTarget, which happens to have an onprogress property.This property is a callback function that gets called with ProgressEvent as an argument.An example of how to set the onprogress property is shown below:
Now that monitoring the upload and download progress is known, integrating this with a jQuery AJAX request is easy.To attach an event listener or set the onprogress property, the instance of XHR that is used by jQuery needs to be adjusted.This can be achieved using the xhr property of $.ajax(), where the creation of XHR is overridden with the function provided, as shown below:
In summary, this post looked at how to monitor the progress of an HTTP request between a client and a server, including both uploading and downloading.The ProgressEvent object contains the information necessary for calculating the progress of a request, which can be gained by either attaching a listener for this event or by setting the onprogress property of the XMLHttpRequest object.Additionally, utilising these two methods with a jQuery AJAX request was shown.
While the request entity body is being uploaded and the upload complete flag is false, queue a task to fire a progress event named progress at the XMLHttpRequestUpload object about every 50ms or for every byte transmitted, whichever is least frequent. - W3 XMLHttpRequest Level 2 (Bolded for emphasis)
When it is said to make progress notifications, while the download is progressing, queue a task to fire a progress event named progress about every 50ms or for every byte received, whichever is least frequent. - W3 XMLHttpRequest Level 2 (Bolded for emphasis)
An XMLHttpRequest object must not be garbage collected if its state is either opened with the send() flag set, headers received, or loading, and it has one or more event listeners registered whose type is one of readystatechange, progress, abort, error, load, timeout, and loadend.
To fire a progress event named e at target, given transmitted and length, means to fire an event named e at target, using ProgressEvent, with the loaded attribute initialized to transmitted, and if length is not 0, with the lengthComputable attribute initialized to true and the total attribute initialized to length.
I am also aware of XHR's progress events should handle gzipped content.Most of what they say just flew over my head, but what I gather is that there is no plan for changing the way lengthComputable is handled when content is gzipped.
Chrome, for example, does not hit the onprogress callback immediately for 'text/plain', but it would if you used 'application/json', for example. Try 'Content-Type: application/json' in your response headers and see if that makes a difference.
XMLHttpRequest (XHR) allows us to listen to various events that can occur while the HTTP request is being processed. This includes error notifications, periodic progress notifications, request abort notifications, and more.
One such event is progress triggered when the downloading starts. For example, when you post something, XMLHttpRequest will first upload our data (the request body) to the server and then downloads the response.
The progress event handler, specified by the xhr.onprogress function above, gets the total number of bytes to transfer and the number of bytes transferred so far in the event's total and loaded properties.
I have a page where users can upload files with the help of FormData and an XMLHttpRequest.Uploading the file works fine. But the upload.onprogress is only working when uploading from an HTTP connection.
The problem is that the XMLHttpRequest progress event is raised with a strange behavior. It reaches too fast 100% when the real upload is not finished, sometimes it's just started, monitored with chrome dev tools and system monitor.
So while the calculated progress is 100% i have too wait long time for send the file with the page apparently stucked. I've read that antivirus can be the reason of that but this is not the case. I don't have antivirus and I turned off firewall too. I tried with both chrome, firefox in windows and ubuntu and libraries such as jquery form plugin with the same behavior.
XMLHttpRequestUpload progress event is dispatched roughly every 50ms. XMLHttpRequestUpload dispatches event as to body transmitted bytes. As far as aware, XMLHttpRequestUpload does not monitor network performance in relation to the transmitted bytes of body, and does not await a response from server.
When it is said to make progress notifications, while the download is progressing, queue a task to fire a progress event named progress about every 50ms or for every byte received, whichever is least frequent.
While the request entity body is being uploaded and the uploadcomplete flag is false, queue a task to fire a progress event namedprogress at the XMLHttpRequestUpload object about every 50ms or forevery byte transmitted, whichever is least frequent.
31c5a71286