3

I have a problem with the upload of a form using javascript and monitoring it's progress.

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.

Someone has an explanation of this strange behavior. What is the XMLHttpRequest progress event loaded attribute actually counting?

Thank you in advance. I fell like banging on the wall for a day.

Here a small piece of code for reproduce the issue:

<?php
echo "Hello!";

if(isset($_FILES['file'])){
    echo " File received";
    return;
}
?>

<form  method='post' action='' enctype='multipart/form-data'>
   <input type='file' name='file' />
   <input type='submit'>
</form>


<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.1.1/jquery.min.js"></script>

<script>

$(document).ready(function(){
    $('form').submit(function(e){
        e.preventDefault();
        ajax = new XMLHttpRequest();
        ajax.onreadystatechange = function ()
        {
            console.log("READY STATE CHANGED");
            console.log(ajax);
        };

        ajax.upload.addEventListener("progress", function (event) {

            var percent = (event.loaded / event.total) * 100;
            console.log(percent);

        });

        ajax.open("POST", $(this).attr('action'), true);
        ajax.send(new FormData(this));
        return false;
    });

});
</script>
Bikappa
  • 86
  • 6
  • 1
    What result are you expecting? – guest271314 Feb 28 '17 at 18:37
  • 1
    I expect that the progress percentage reaches 100℅ when the last byte of the request is sent to the server. Instead I see 100℅, for example, in 5 seconds when the upload take more than 10 to complete – Bikappa Feb 28 '17 at 18:52
  • 1
    Not sure what you mean? The bytes still need to be transmitted over network to server. How do you know that the process took 10 seconds to complete? Are you expecting `echo " File received";` to be called at exactly `event.total` equal to `event.loaded`? `progress` event dispatches transmitted bytes, though does not monitor the bytes once sent over network. – guest271314 Feb 28 '17 at 19:20
  • 1
    I know from network traffic monitor and chrome Dev tools. What happens is: progress reaches 100℅ in 4/5 seconds (sometimes it start from above 60℅ and this doesn't make sense, how can the network transmit so fast?), traffic monitor say that an upload is taking place for 12 seconds while chrome Dev tools report request as "pending", finally response arrives and network traffic goes to 0 as well. – Bikappa Feb 28 '17 at 19:22
  • 1
    Yes, `progress` event is dispatched roughly every 50ms. `progress` event is not dispatched in real time _"If not roughly 50ms have passed since these subsubsteps were last invoked, terminate these subsubsteps."_ , _"If upload listener flag is set, then fire a progress event named progress on the `XMLHttpRequestUpload` object with request’s body’s transmitted bytes and request’s body’s total bytes."_ https://xhr.spec.whatwg.org/#xmlhttprequestupload . – guest271314 Feb 28 '17 at 19:23
  • See also [How to read and echo file size of uploaded file being written at server in real time without blocking at both server and client?](http://stackoverflow.com/q/42475492/) – guest271314 Feb 28 '17 at 19:28
  • Ok but my bandwidth can not reach that performance, is impossible. I have a test file of 1MB and an upload bandwidth of 0.1 MB/s (more or less :() so an upload time of 10 seconds is reasonable. But progress reaches 100℅ in 5 seconds (not expected) and response is received in 12 seconds (expected) – Bikappa Feb 28 '17 at 19:29
  • As far as am aware here, `progress` event does not monitor network, `progress` only provides transmitted bytes of body roughly every 50ms. – guest271314 Feb 28 '17 at 19:32
  • I know that, but progress should not be "100℅" when the transmission of payload is taking place for others 6/7 seconds. It's should be 100℅ when last byte of the payload is sent, and after this byte reaches the server and request is processed (let say 250ms) I should received the response. So between '100℅' and response the elapsed time should be 250ms and not 6 seconds as occuring. Is that wrong? – Bikappa Feb 28 '17 at 19:39
  • See https://www.w3.org/TR/2011/WD-XMLHttpRequest2-20110816/#make-upload-progress-notifications. `progress` event reads transmitted bytes of body, not the duration it takes for transmitted bytes to reach server, or server response time. – guest271314 Feb 28 '17 at 19:43
  • Sorry but it seems you miss the point. I know what you are saying. But after progress 100℅ I expect a time of (250-500 ms) before reaching the response (ping + processing + ping circa). But it's is 5/6 seconds with a file of 1 Mb and proportionally more for larger files. – Bikappa Feb 28 '17 at 19:57
  • _"But after progress 100℅ I expect a time of (250-500 ms) before reaching the response (ping + processing + ping circa)."_ Why do you have that specific expectation? – guest271314 Feb 28 '17 at 20:00
  • It's a big over estimation of the time for a packet to reach the server and to receive back the response which is a small echo string. – Bikappa Feb 28 '17 at 21:35
  • `XMLHttpRequest` is asynchronous. What is your estimation based on? Are you expecting exacting mathematical results as to computer networking? Are you sure that your request is not routed through different servers or relay switches in both directions? Have you tried the same procedure at different computers? You have the actual results. Not sure how network response from `php` is related to `XMLHttpRequestUpload` `progress` event? – guest271314 Feb 28 '17 at 21:39
  • Is based on the fact that a get request complete (with response received) in less than 50ms. From the last packet of a post request departure and the reception of the response that should be the elapsed time. Otherwise it means the I have progress 100℅ while the request is not entirely sended. By this point is yet evident looking at the network upload traffic of the client (when I see 100℅ client is still sending data for seconds and seconds, and the time it's take from "last byte sended, ie 100℅" to response received is proportional to the size of the file which is absurd. – Bikappa Feb 28 '17 at 21:49
  • The time from "last byte" and response should be the same in the case of a big file. But that is not what's going on. – Bikappa Feb 28 '17 at 21:50
  • _"The time from "last byte" and response should be the same"_ How did you come to this conclusion? If you have determined that there is a bug at native implementation of `XMLHttpRequest`, `XMLHttpRequestUpload` or `progress` event of `XMLHttpRequestUpload` perhaps consider filing an issue at [github](https://github.com/whatwg/xhr). – guest271314 Feb 28 '17 at 21:58
  • Why it's should be not the same? – Bikappa Feb 28 '17 at 22:07
  • How can you reliably predict network traffic? Have you traced the route the packets take to server? `progress` event is not real time, appears to only provide how many bytes have been transmitted, not whether or not the server has received the bytes. `php` has to handle `$_FILES['file']`, then `echo`, all of which take time, which is probably not the exact same time at each request. – guest271314 Feb 28 '17 at 22:13
  • 50ms vs 5/6 secs with a 1MB file and 10 secs with a 2MB file is not variability of network traffic. During this secs the client show that it IS sending data but the progress 100℅ and this should means the all data was already sent (and is traveling through the network). – Bikappa Feb 28 '17 at 22:18
  • Not certain what Question? Do you believe that a bug exists as to browser implementation of `XMLHttpRequestUpload` `progress` event? – guest271314 Feb 28 '17 at 22:20
  • 1
    I know this issue is pretty old, but i might be able to add some information to this issue. This seems to happen only on windows. We are experiencing the same issue on one of our pages. Uploading a 60MB file with ~0.4mb/s jumps to 100% on Windows within two seconds...leaving us to wait for the response for another few minutes - happening on all major browsers. The same on Linux (Chrome and Firefox) shows progress at ~0.4 mb/s...which should be the desired behavior. – Tobi Jul 26 '17 at 07:15
  • I am having the exact same issue, did you ever resolve this? – Phil Jan 18 '21 at 16:53

1 Answers1

2

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.

See Make upload progress notifications

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.

When it is said to make upload progress notifications run these steps:

  • 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.

  • If the request entity body has been successfully uploaded and the upload complete flag is still false, queue a task to run these substeps:

    1. Set the upload complete flag to true.

    2. Fire a progress event named load at the XMLHttpRequestUpload object.

    3. Fire a progress event named loadend at the XMLHttpRequestUpload object.


See also How to read and echo file size of uploaded file being written at server in real time without blocking at both server and client?

Community
  • 1
  • 1
guest271314
  • 1
  • 15
  • 104
  • 177
  • This doesn't address the actual problem. See Tobi's comment on the question. It seems to be a Windows bug. – Tim S. Jan 27 '21 at 16:01